Skip to content

0039. Tests e2e: base aislada y desechable, reset por SQL directo (no migrate reset)

Estado

Aceptada

Contexto

Los tests e2e del backend corrían contra camaroneras_dev (misma base que desarrollo) y limpiaban a mano con afterAll atado a los emails creados. Resultado: cada corrida dejaba basura en la base de desarrollo (entidades no atadas a esos emails, o tests que fallaban antes del afterAll, o Ctrl-C).

Decisión

Aislar los tests en una base desechable camaroneras_test que se resetea al inicio de cada corrida (globalSetup de Jest). Tres decisiones no obvias:

  1. Reset con prisma migrate deploy + TRUNCATE por SQL directo, NO prisma migrate reset. Prisma 7 trae un guard anti-IA que bloquea migrate reset cuando detecta que lo invoca un agente (Claude Code) y exige PRISMA_USER_CONSENT_FOR_DANGEROUS_AI_ACTION. Como los tests se corren desde Claude Code (skill pm-cerrar-tarea), reset los bloquearía. migrate deploy es forward-only (no destructivo → sin guard) y un TRUNCATE de todas las tablas (salvo _prisma_migrations) vacía los datos manteniendo el esquema; además es más rápido.

  2. El script test:e2e corre con --runInBand (en serie). Los specs comparten una sola base; en paralelo, los onModuleInit de varios workers siembran los catálogos (permisos, tipos de equipo) a la vez sobre una base recién creada y compiten → fallos intermitentes. En serie es determinista. (Con la base "tibia" no se notaba porque los upserts ya eran no-op; el bug solo aparece sobre una base fresca, ej. un clon nuevo.)

  3. globalSetup auto-crea la base si no existe. docker compose up solo crea camaroneras_dev. Para que un clon nuevo funcione sin CREATE DATABASE manual, el setup se conecta a la base postgres y crea camaroneras_test si falta. Un guard aborta si DATABASE_URL no contiene camaroneras_test, para no tocar nunca la base equivocada.

No se corre seed: los catálogos se re-siembran solos en el onModuleInit de sus servicios al bootear AppModule.

Consecuencias

  • camaroneras_dev nunca se toca; los afterAll de limpieza manual quedan redundantes (pendiente removerlos — ver backlog).
  • Cada dev debe crear su .env.test local (gitignored) con DATABASE_URLcamaroneras_test (documentado en .env.template y el CLAUDE.md del backend). La base se auto-crea.
  • Si se agrega un prisma db seed, revisar que el TRUNCATE no borre datos que el seed espera persistentes entre corridas.