Probar contra lo real en lugar de contra un simulacro

Su suite de pruebas está en verde. Trescientas cuarenta pruebas, once segundos, ningún fallo. Despliega, y la primera petición en producción falla con ERROR: column "created_at" is of type timestamp with time zone but expression is of type character varying. Nadie ha introducido un bug: el código probado es exactamente el código desplegado. Lo que ha cambiado es la base de datos. Sus pruebas hablaban con H2 en modo de compatibilidad con PostgreSQL, y producción habla con PostgreSQL 16. H2 aceptaba la conversión implícita, PostgreSQL la rechaza. Su suite no mintió sobre su código, mintió sobre su entorno.

Este escenario no tiene nada de exótico. H2 no conoce jsonb, no aplica las mismas reglas de ordenación de cadenas según la colación, acepta nombres de columna que PostgreSQL reserva y trata los niveles de aislamiento transaccional con una flexibilidad que Oracle o SQL Server no tienen. Cada diferencia es pequeña. Juntas forman una categoría entera de defectos que su suite no puede detectar estructuralmente, y sobre los que no tiene ninguna señal antes del despliegue. El problema no es H2: es creer que una prueba que pasa contra H2 dice algo sobre PostgreSQL.