Dati di test per indirizzi sintetici: progettare fixture riproducibili

Le fixture fisse e casuali svolgono compiti diversi

Gli appuntamenti fissi si adattano a istantanee, contratti e migrazioni. La generazione casuale espande le combinazioni, ma senza un seme crea fallimenti che nessuno può riprodurre.

Conserva un piccolo set di regressione revisionato e un generatore che accetta seed, paese e scenario. Promuovere i fallimenti utili in fixture fissi.

Riconoscibile senza rompere il formato

Utilizza domini riservati come example.com, aggiungi dataPurpose e fixtureId e registra fixtureId invece di un indirizzo completo. Mantieni la forma postale realistica durante il test di un parser.

Non copiare mai un cliente e sostituire solo il nome. Altri campi possono ancora identificare una persona o inviare notifiche.

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

Casuale non significa incoerente

Definisci invarianti: il formato del paese concorda, i campi regionali provengono da una tupla, i codici postali rimangono testo e le righe opzionali rimangono vuote anziché N/D. I test sulle proprietà possono verificarli su molti semi.

Un fixture non valido può interrompere un'invariante, ma dovrebbe dichiarare expectedError in modo che nessuno lo tratti come dati normali.

• Ogni seme è rigiocabile
• Le tuple regionali normali rimangono coerenti
• Le fixtureature non valide infrangono una regola denominata
• L'output registra la versione dei dati di riferimento

Prevenire gli effetti collaterali della produzione

Testa le integrazioni di e-mail, SMS, stampa, evasione e pagamento tramite sandbox o blocchi in uscita. Scrivere Test in un indirizzo non impedisce una vera e propria chiamata logistica.

Il CI dovrebbe verificare i tipi di ambiente e credenziali e rifiutare i record di test sintetici che entrano nelle code di produzione.

Trasforma i fallimenti in risorse di regressione

Conservare il record minimo di errori, il seed, la versione dei dati e l'asserzione. Deduplica periodicamente, ma non rigenerare i fixture stabili semplicemente per farli sembrare nuovi.

Assegna a ogni evento fisso un proprietario, uno scenario, un risultato previsto, un motivo per la creazione e una data di revisione. Un file JSON di grandi dimensioni che non spiega il comportamento che protegge diventa rapidamente un mucchio di cui nessuno si fida e nessuno osa eliminare. Durante la revisione, identificare la copertura duplicata e le regole a cui il prodotto non si applica più.

Non acquisire istantanee dell'interfaccia utente dall'output casuale senza restrizioni. Utilizzare un record fisso esplicito per gli snapshot e consentire ai test casuali di affermare proprietà e invarianti. Questa divisione impedisce la produzione di istantanee senza senso ogni volta che una strada generata cambia, pur preservando un'ampia copertura esplorativa.

Tratta un aggiornamento dei dati di riferimento come una modifica della dipendenza. Esegui il vecchio set di semi rispetto alla nuova istantanea, esamina le differenze intenzionali e conserva entrambe le versioni abbastanza a lungo da spiegare perché un record precedentemente riproducibile è cambiato.

Tieni traccia della copertura per scenario, non per numero grezzo di righe generate. Diecimila indirizzi ordinari non sostituiscono un fixture deliberato per un'unità mancante, un codice postale con zero iniziale, un nome di edificio troppo lungo o una regione non supportata. Una matrice di copertura compatta consente ai revisori di vedere quale regola esercita ogni fixture e dove il generatore presenta ancora punti ciechi.

• Assegnare un proprietario e un comportamento protetto
• Esamina i casi duplicati e obsoleti
• Utilizza fixture fissi per le istantanee e fixture casuali per le proprietà
• Aggiornamenti dei dati di riferimento della versione in modo esplicito