English

Prueba los invariantes de datos en la capa de la base de datos

La validación de tu app es una sugerencia. La restricción de tu base de datos es una ley. Las verificaciones a nivel de aplicación solo corren cuando las escrituras pasan por tu aplicación — y tu aplicación no es la única que escribe. Migraciones, scripts de backfill, consolas de administración, cron jobs y otros servicios tocan las mismas tablas. Si un invariante importa — "los emails son únicos", "toda orden tiene un cliente", "la cantidad nunca es negativa" — debe imponerse donde todo escritor tiene que pasar: la base de datos. Y luego hay que probarlo ahí, no solo declararlo.

Por qué las verificaciones de la app fallan

Una validación de ORM tipo unique: true suele hacer un SELECT y luego un INSERT. Dos peticiones concurrentes pueden pasar ambas el SELECT e insertar ambas — lo único que realmente detiene el duplicado es una restricción única en la base de datos. El mismo patrón se repite en todas partes: verificaciones de presencia que un backfill en SQL crudo se salta, reglas de "no negativo" que un script de corrección de datos nunca conoció, filas huérfanas dejadas por un servicio que no carga tus modelos. Las verificaciones de la app son buena UX; no son integridad.

Prueba sobre una base de datos real y desechable

1. Levanta una instancia desechable del mismo motor y versión mayor que producción. Testcontainers hace exactamente eso — contenedores de bases de datos desechables, definidos como código, con librerías para Java, Go, .NET, Node.js, Python, Rust y más.
2. Corre tus migraciones reales contra ella, desde cero. El esquema bajo prueba es el que despliegas — no un fixture mantenido a mano.
3. Siembra filas que ataquen cada restricción: inserta una llave duplicada, borra una fila padre con hijos, inserta un valor que el check constraint prohíbe — y verifica que la base de datos rechace cada una.
4. Destrúyela. La siguiente corrida arranca limpia.

Una prueba que espera que el INSERT falle es la prueba de que la ley existe. Si alguien elimina la restricción en una migración, esta prueba — y no un incidente en producción — lo detecta.

Trampas por motor que merecen una prueba cada una

Cada fila de esa tabla es una razón por la que una base de datos simulada o "compatible" en memoria da falsa confianza. Prueba contra el motor que despliegas.

Movidas de usuario avanzado

• Prueba el esquema en sí, en SQL. pgTAP permite escribir pruebas TAP dentro de PostgreSQL — has_table(), has_column(), col_is_pk() — para verificar la existencia de la restricción, no solo su comportamiento.
• Verifica el error, no solo el fallo. Revisa el nombre de la restricción en el rechazo (p. ej. users_email_key) para que la prueba falle en voz alta si otro error enmascara una restricción eliminada.
• Ejercita la concurrencia donde importa. Para unicidad, dispara dos inserciones en transacciones paralelas; solo una base de datos real reproduce la carrera que la verificación de la app pierde.
• Mantén un script de semillas con datos "hostiles". Un conjunto pequeño y versionado de filas diseñadas para violar cada invariante sirve también como documentación viva de lo que el esquema garantiza.

Recursos

• PostgreSQL — Constraints (CHECK, UNIQUE, NOT NULL, FK)
• Testcontainers — contenedores de bases de datos desechables para pruebas
• SQLite — soporte de llaves foráneas y PRAGMA foreign_keys
• MySQL 8.4 — CHECK constraints
• pgTAP — pruebas unitarias dentro de PostgreSQL