Datos de prueba de direcciones sintéticas: diseño de fixtures reproducibles

Los fixtures fijos y aleatorios cumplen funciones distintas

Los fixtures fijos se adaptan a instantáneas, contratos y migraciones. La generación aleatoria amplía las combinaciones, pero sin una semilla crea fallos que nadie puede repetir.

Mantenga un pequeño conjunto de regresión revisado y un generador que acepte semilla, país y escenario. Promover fallas útiles en fixtures fijos.

Reconocible sin romper el formato.

Utilice dominios reservados como example.com, agregue dataPurpose y fixtureId y registre fixtureId en lugar de una dirección completa. Mantenga la forma postal realista al probar un analizador.

Nunca copie a un cliente y reemplace solo el nombre. Otros campos aún pueden identificar a una persona o enviar notificaciones.

{
  "fixtureId": "ca-boundary-003",
  "dataPurpose": "synthetic-test",
  "seed": 7319,
  "countryCode": "CA",
  "email": "qa-7319@example.com"
}

Aleatorio no significa inconsistente

Defina invariantes: el formato del país coincide, los campos regionales provienen de una tupla, los códigos postales siguen siendo texto y las líneas opcionales permanecen vacías en lugar de N/A. Las pruebas de propiedad pueden verificarlas en muchas semillas.

Un fixture no válido puede romper una invariante, pero debe declarar expectedError para que nadie lo trate como datos normales.

• Cada semilla es rejugable
• Las tuplas regionales normales se mantienen consistentes
• Los partidos no válidos infringen una regla nombrada
• La salida registra la versión de los datos de referencia.

Evitar efectos secundarios en producción

Pruebe las integraciones de correo electrónico, SMS, impresión, cumplimiento y pagos a través de entornos sandbox o bloques salientes. Escribir Test en una dirección no impide una llamada logística real.

CI debe verificar los tipos de credenciales y entornos y rechazar los registros de pruebas sintéticas que ingresan a las colas de producción.

Convierta los fracasos en activos de regresión

Mantenga el registro, la semilla, la versión de datos y la aserción mínimos fallidos. Deduplica periódicamente, pero no regeneres fixtures estables simplemente para que luzcan nuevos.

Proporcione a cada fixture fijo un propietario, escenario, resultado esperado, motivo de creación y fecha de revisión. Un archivo JSON de gran tamaño que no explica el comportamiento que protege rápidamente se convierte en una pila en la que nadie confía y nadie se atreve a eliminar. Durante la revisión, identifique coberturas duplicadas y reglas que el producto ya no aplica.

No tome instantáneas de la interfaz de usuario desde una salida aleatoria sin restricciones. Utilice un registro fijo explícito para instantáneas y permita que las pruebas aleatorias afirmen propiedades e invariantes. Esa división evita la rotación de instantáneas sin sentido cada vez que cambia una calle generada y, al mismo tiempo, preserva una amplia cobertura exploratoria.

Trate una actualización de datos de referencia como un cambio de dependencia. Ejecute el conjunto de semillas antiguo con la nueva instantánea, revise las diferencias intencionales y conserve ambas versiones el tiempo suficiente para explicar por qué cambió un registro previamente reproducible.

Realice un seguimiento de la cobertura por escenario, no por el número bruto de filas generadas. Diez mil direcciones ordinarias no reemplazan un fixture deliberado para una unidad faltante, un código postal con cero inicial, un nombre de edificio demasiado largo o una región no admitida. Una matriz de cobertura compacta permite a los revisores ver qué regla ejerce cada fixture y dónde el generador todavía tiene puntos ciegos.

• Asignar un propietario y un comportamiento protegido
• Revisar casos duplicados y obsoletos
• Utilice fixtures fijos para instantáneas y elementos aleatorios para propiedades
• Actualizaciones de datos de referencia de versión explícitamente