¿Cómo gestionas datos de prueba?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Los buenos datos de prueba son mínimos, deterministas y propiedad de la prueba que los necesita. Se crean con las mismas APIs o factorías que usa el producto, para que sigan siendo válidos cuando cambia el esquema, con valores por defecto para lo irrelevante y sobrescrituras explícitas para lo que trata la prueba. Cada prueba o worker tiene su propio espacio, como un tenant único o un identificador con prefijo, para que las ejecuciones en paralelo y las repeticiones no colisionen. Los datos personales reales nunca entran en entornos de prueba; las muestras con forma de producción se sintetizan o enmascaran. Relojes, semillas e identidades se controlan para que los resultados se repitan, y la limpieza es automática mediante bases de datos desechables o innecesaria porque los datos están aislados.

Ejemplo

Una prueba que comprueba recordatorios de facturas vencidas llama a las factorías createCustomer y createInvoice con una fecha de vencimiento explícita, corre contra un esquema de base de datos creado por worker y congela el reloj tres días después del vencimiento. Una instantánea enmascarada de producción, con nombres, emails y datos de tarjeta sustituidos, siembra el entorno de rendimiento cada mes. Nadie copia volcados de producción a portátiles.

Errores frecuentes

• Compartir una base de datos sembrada entre pruebas que la modifican.
• Codificar IDs que solo existen en un entorno.
• Copiar datos reales de clientes a sistemas de prueba.

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.