¿Cómo automatizas la preparación de datos de prueba?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Los datos de prueba automatizados vienen de factorías o de las propias APIs del producto, nunca de volcados SQL mantenidos a mano. Una factoría como createOrder construye un objeto válido con valores por defecto sensatos y acepta sobrescrituras para los atributos que importan a la prueba, de modo que las pruebas solo declaran lo relevante y siguen válidas cuando el modelo evoluciona. Las identidades se generan únicas por llamada, la preparación es idempotente para que una repetición no falle por duplicado, y cada ejecución o worker se aísla por tenant o espacio. Las muestras sensibles de producción se enmascaran antes de ser fixtures. La limpieza se evita usando bases de datos o espacios desechables en lugar de scripts de desmontaje frágiles.

Ejemplo

Una prueba que necesita una factura vencida llama a createInvoice({ dueDate: daysAgo(10), status: 'unpaid' }); la factoría crea el cliente y la cuenta a través de la API pública con un email generado, y todo lo demás toma valores por defecto. Las pruebas de rendimiento siembran 100.000 pedidos con las mismas factorías en un esquema desechable. Cuando el modelo de factura ganó un campo obligatorio de moneda, solo cambió la factoría y 300 pruebas siguieron pasando.

Errores frecuentes

• Mantener un fichero SQL de semilla gigante que se rompe con cada cambio de esquema.
• Reutilizar IDs fijos, de modo que las pruebas paralelas y las repeticiones colisionan.
• Escribir scripts de desmontaje que dejan datos parciales cuando una prueba falla a medias.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.