PostgreSQL
Seeds, fixtures y datos de prueba
Diseño de seeds, fixtures y datos de prueba reproducibles, diferenciando datos de referencia, escenarios de testing y contenido de demostración.
- Última actualización
- Actualizada
- Nivel
- Aplicación
PostgreSQL
Diseño de seeds, fixtures y datos de prueba reproducibles, diferenciando datos de referencia, escenarios de testing y contenido de demostración.
Seeds, fixtures y datos de prueba cumplen propósitos distintos. Mezclarlos produce suites frágiles, entornos inconsistentes y riesgo de insertar información falsa en producción.
seed
→ datos de referencia o bootstrap necesarios
fixture
→ escenario controlado para una prueba
factory
→ constructor programático de datos válidos
demo data
→ información ficticia para mostrar el productoCada categoría necesita lifecycle y permisos diferentes.
Ejemplos:
Deben ser idempotentes:
INSERT INTO document_types(code, name)
VALUES ('CC','Cédula de ciudadanía')
ON CONFLICT (code)
DO UPDATE SET name = EXCLUDED.name;Pero no uses upsert destructivo si los administradores pueden personalizar el valor. Define ownership del dato.
No dependas de IDs autogenerados diferentes por entorno:
code text PRIMARY KEYo UUIDs fijos documentados. Las relaciones de seed deben usar claves naturales/estables.
Datos estrictamente necesarios para que una migration o feature funcione pueden viajar en una migration versionada. Datos de demo o grandes catálogos cambiantes suelen pertenecer a un proceso separado.
No edites un seed histórico esperando que entornos existentes lo vuelvan a ejecutar.
Una fixture expresa el escenario mínimo:
customer activo
+ order pending
+ inventory con 1 unidadDebe ser legible y específica. Una fixture global con cientos de filas crea acoplamiento: una prueba cambia un dato y rompe otra.
En TypeScript:
const buildOrder = (overrides = {}) => ({
status: 'pending',
totalAmount: '100.00',
...overrides,
});La factory genera objetos; el helper de persistencia decide transacciones, IDs y relaciones.
Evita defaults aleatorios invisibles. Un fallo debe reproducirse con seed conocido.
Los datos deben representar:
No necesitas copiar producción para cada test, pero una base vacía no revela planes ni problemas de volumen.
Cada test abre una transacción y hace rollback. Es rápido, pero no sirve si el código abre conexiones independientes o prueba commit/failover.
Limpia tablas entre pruebas; debe respetar FKs/sequences y puede ser costoso.
Aísla suites paralelas, a cambio de setup y migrations.
Alta fidelidad; cuida tiempo de arranque y versionado.
No reutilices claves globales como test@example.com sin aislamiento. Usa namespaces deterministas por worker/test y limpia recursos.
Después de fixtures explícitas, no asumas IDs. Usa RETURNING. Reiniciar identity puede facilitar snapshots, pero no debe convertirse en contrato de la prueba.
Nunca copies producción sin anonimización fuerte y autorización. El masking debe cubrir:
Una copia en laptop o CI amplía superficie de fuga.
Debe estar marcada como ficticia, poder resetearse y no mezclarse con tenants reales. Un proceso recurrente puede restaurar el estado esperado.
Para índices/planner necesitas volumen y distribución, no solo cantidad:
95% paid
0.1% pending
un tenant gigante
muchos tenants pequeñosGenera estadísticas y ejecuta ANALYZE.
Fija:
Cuando una prueba fuzz encuentra un fallo, registra la seed para reproducirlo.
crear database limpia
→ migrations
→ seeds de referencia
→ fixture específica
→ test
→ limpieza/descartar databaseVerifica que migrations desde cero y desde versión anterior produzcan el mismo contrato.
Backups, restauración y PITR demuestra que los datos pueden recuperarse, no solo que se generó un archivo.