Postgres rechaza un enum que H2 dejaba pasar: falla en produccion por divergencia de esquemas
Un equipo descubre que sus pruebas verdes ocultaban un error de tipado porque H2 no soporta nativamente los tipos enum de PostgreSQL. La solucion migrar a Testcontainers.
La suite de pruebas estaba en verde. La migracion funciono en H2, los tests de repositorio pasaron, el pipeline hizo su trabajo y el cambio salio a produccion. Horas despues, un trabajo por lotes que modificaba registros de categoria colapo con un error inesperado: invalid input value for enum category_status.
El problema no estaba en el codigo de la aplicacion, sino en la divergencia silenciosa entre el entorno de pruebas y el de produccion. Durante un refactoring anterior en el ano, el equipo habia cambiado el campo de estado de una bandera suelta a un tipo de tres valores: ACTIVE, INACTIVE y ARCHIVED. En la base de datos de produccion, que usa PostgreSQL, esto se implemento como un tipo enum nativo. La base de datos impone la restriccion y rechaza cualquier valor que no este en esa lista cerrada.
En el entorno de desarrollo y pruebas, el equipo usaba H2. Como esta base de datos en memoria no soporta los tipos enum nativos de PostgreSQL, el script de migracion para el entorno de pruebas definio la columna como una simple cadena de texto (VARCHAR). Ambos entornos pasaron sus respectivas pruebas. El trabajo por lotes intentaba escribir un valor legado, LEGACY_HIDDEN, que habia valido antes del refactoring. H2 acepto la cadena sin cuestionar. PostgreSQL, haciendo exactamente lo que un tipo estricto debe hacer, rechazo el insert y detuvo el proceso.
El fallo revela una trampa comun en la ingenieria de software: las pruebas no validaban la correccion de los datos, solo que el codigo se ejecutaba sin lanzar excepciones de sintaxis. El esquema de pruebas era incapaz de detectar la clase de error que la base de datos de produccion obligaba a gestionar.
De H2 a Testcontainers
La solucion implementada por el equipo no fue parchear el trabajo por lotes para que ignorara el valor antiguo, aunque eso hubiera sido una solucion rapida al sintoma. Cambiaron la estrategia de pruebas. Migraron la suite a Testcontainers, una herramienta que permite levantar instancias reales de bases de datos en contenedores Docker durante la ejecucion de las pruebas.
Al correr los tests de cobertura del trabajo por lotes contra un contenedor de PostgreSQL real, usando el mismo script de migracion que en produccion, la prueba fallo en el primer intento. El error local fue identico al incidente en produccion: el mismo valor de enum invalido rechazado por la base de datos. En diez minutos de investigacion, el equipo recupero el comportamiento de produccion en su maquina local y pudo corregir la logica del lote antes de que el error volviera a llegar a los usuarios.
La conclusión tecnica es directa. H2 es una herramienta rapida y valida para muchas pruebas unitarias que no dependen de la semantica de la base de datos. Pero tiene un limite claro: cualquier logica que la base de datos de produccion ejecute por si misma mediante restricciones, tipos estrictos o reglas de exclusion, debe ser probada contra un motor que pueda ejecutar esa misma logica. Si el esquema hace trabajo real, las pruebas deben usar una base de datos que haga ese trabajo. De lo contrario, los tests verdes solo garantizan que el codigo no truena, no que los datos sean correctos.
