Testgegevens voor synthetische adressen: reproduceerbare testfixtures ontwerpen

Vaste en willekeurige testfixtures hebben verschillende doelen

Vaste testfixtures zijn geschikt voor snapshots, contracten en migraties. Willekeurige generatie breidt combinaties uit, maar zonder een zaadje ontstaan ​​er mislukkingen die niemand opnieuw kan spelen.

Houd een kleine, herziene regressieset bij en een generator die zaad, land en scenario accepteert. Promoot nuttige fouten in vaste testfixtures.

Herkenbaar zonder het formaat te verbreken

Gebruik gereserveerde domeinen zoals example.com, voeg dataPurpose en fixtureId toe en log fixtureId in plaats van een volledig adres. Houd de postvorm realistisch bij het testen van een parser.

Kopieer nooit een klant en vervang alleen de naam. Andere velden kunnen nog steeds een persoon identificeren of meldingen verzenden.

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

Willekeurig betekent niet inconsistent

Definieer invarianten: het landformaat komt overeen, regionale velden komen uit één tuple, postcodes blijven tekst en optionele regels blijven leeg in plaats van N.v.t. Eigenschapstesten kunnen deze voor veel zaden controleren.

Een ongeldige testfixture kan één invariant doorbreken, maar moet expectedError declareren, zodat niemand het als normale gegevens behandelt.

• Elk zaadje is herspeelbaar
• Normale regionale tupels blijven consistent
• Ongeldige wedstrijden overtreden één benoemde regel
• Uitvoer registreert de versie van de referentiegegevens

Voorkom productiebijwerkingen

Test e-mail-, SMS-, afdruk-, uitvoerings- en betalingsintegraties via sandboxes of uitgaande blokken. Het schrijven van Test in een adres staat een echt logistiek telefoontje niet in de weg.

CI moet omgevings- en inloggegevens verifiëren en synthetische testrecords weigeren die de productiewachtrijen binnenkomen.

Verander mislukkingen in regressiemiddelen

Bewaar het minimale falende record, zaad, gegevensversie en bewering. Ontdubbel periodiek, maar regenereer geen stabiele testfixtures alleen maar om ze er fris uit te laten zien.

Geef elke vaste testfixture een eigenaar, scenario, verwachte uitkomst, reden van creatie en beoordelingsdatum. Een groot JSON-bestand dat het gedrag dat het beschermt niet verklaart, wordt al snel een stapel die niemand vertrouwt en die niemand durft te verwijderen. Identificeer tijdens de beoordeling dubbele dekking en stel vast dat het product niet langer van toepassing is.

Maak geen UI-snapshots van onbeperkte willekeurige uitvoer. Gebruik een expliciet vast record voor snapshots en laat willekeurige tests eigenschappen en invarianten bevestigen. Deze verdeling voorkomt een zinloos momentopnameverloop wanneer een gegenereerde straat verandert, terwijl toch een brede verkennende dekking behouden blijft.

Behandel een upgrade van referentiegegevens als een wijziging in de afhankelijkheid. Voer de oude zaadset uit tegen de nieuwe momentopname, bekijk opzettelijke verschillen en bewaar beide versies lang genoeg om uit te leggen waarom een ​​eerder reproduceerbaar record is gewijzigd.

Volg de dekking per scenario, niet op basis van het ruwe aantal gegenereerde rijen. Tienduizend gewone adressen kunnen niet één opzettelijke vermelding vervangen door een ontbrekende eenheid, een postcode met voorloopnul, een te lange gebouwnaam of een niet-ondersteunde regio. Dankzij een compacte dekkingsmatrix kunnen reviewers zien welke regel elke testfixture toepast en waar de generator nog blinde vlekken heeft.

• Wijs een eigenaar toe en bescherm gedrag
• Beoordeel dubbele en verouderde aanvragen
• Gebruik vaste testfixtures voor snapshots en willekeurige testfixtures voor eigendommen
• Versiereferentiegegevens-upgrades expliciet