Adrestestdata is meestal de laatste fixtureset die iemand organiseert, en de eerste die nutteloos wordt. Het begint als een handvol reeksen die in een seedscript zijn geplakt, groeit met één regel telkens wanneer een bug wordt opgelost, en eindigt als veertig bijna identieke voorbeelden die niemand begrijpt en iedereen bang is te verwijderen.
Dit artikel beschrijft een manier om de gegevens te ordenen zodat ze leesbaar blijven: gegroepeerd per land en per scenario, reproduceerbaar vanuit een gedocumenteerde oorsprong, en duidelijk gemarkeerd als synthetisch zodat geen enkele toekomstige lezer ze voor een klantrecord aanziet.
Begin bij scenario’s, niet bij landen
De instinctieve reactie is om fixtures per geografie te ordenen — één voorbeeld per bediend land. Dat levert een lange lijst met heel weinig dekking op, want wat een adrespijplijn breekt is zelden het land zelf. Het is een specifieke vorm van gegevens: een ontbrekende postcode, een te lange straatregel, een unitdetail, een niet-Latijns schrift, een regio die niet overeenkomt met zijn postcode.
Orden eerst per scenario en noteer het land binnen elk scenario. Een werkbare startset ziet er zo uit.
| Scenario | Wat het test | Voorbeeldvorm |
|---|---|---|
| Minimaal adres | Alleen vereiste velden, geen unit, geen district | Straat, plaats, onderverdeling, postcode |
| Volledig adres | Elk optioneel veld aanwezig | Voegt unit, gebouw, district, tweede regel toe |
| Ontbrekende postcode | Veld optioneel in sommige landen | Een land waarvan de adressen geen code dragen |
| Postcode met alleen cijfers | Tekstopslag, voorloopnullen | Een code waarvan het eerste teken nul is |
| Postcode met letters en cijfers | Tekenklassen en scheidingstekens | Een code met tussengevoegde letters |
| Te lange straatregel | Lengtelimieten en afkapping | Een lange naam plus een unitdetail |
| Niet-Latijns schrift | Tekenset en weergave | Een naam in een niet-Latijns schrijfsysteem |
| Inconsistente regio | Relationele controles | Een regio die die postcode niet kan huisvesten |
Die set is klein, en dekt meer faalmodi dan een voorbeeld uit alle ruim tachtig landen zou doen. Het land dat niets test, is het land dat iedereen al ondersteunt.
Waarom moeten adresfixtures reproduceerbaar zijn?
Een adresfixture die niet kan worden geregenereerd, is een fixture die niemand vertrouwt. Als de gegevens ooit ergens zijn gekopieerd en de bron is weg, dan kun je bij een falende test niet zeggen of de fout een regressie in je code is of een verandering in een waarde die er toevallig stond.
Reproduceerbaarheid betekent dat dezelfde invoer dezelfde uitvoer oplevert, op elke machine, op elk moment. Twee manieren om daar te komen. Ofwel de waarden worden deterministisch uit een identificatie afgeleid — dezelfde seed, hetzelfde adres, elke run — ofwel de waarden worden als bestanden ingecheckt en nooit met de hand bewerkt. Wat niet werkt, is een generator die bij elke aanroep een ander voorbeeld teruggeeft en dat in de fixture schrijft, want dan vergelijken twee engineers die dezelfde test draaien tegen verschillende gegevens.
Deterministische generatie heeft een tweede voordeel in staging-omgevingen. Een record dat tweemaal wordt geladen, draagt hetzelfde adres, dus een herrun creëert geen duplicaten die alleen in hun adresvelden verschillen, en een screenshot van vorige week komt nog steeds overeen met het record dat je vandaag bekijkt.
Waarom echte klantadressen hier nooit horen
Productieadressen naar een test- of staging-omgeving kopiëren is de meest voorkomende gegevensbeschermingsfout op dit gebied, en het is makkelijk te begrijpen waarom mensen het doen: de gegevens zijn realistisch, ze zijn er al, en niemand hoeft over dekking na te denken.
Een adres is persoonsgegeven. Het identificeert een persoon, of een heel kleine groep personen, en in combinatie met een naam, een bestelgeschiedenis of een accountidentificatie is het genoeg om iemand vindbaar te maken. Een staging-database die door productie te kopiëren is opgebouwd, erft dat allemaal, meestal met zwakkere toegangscontroles, meer kopieën op meer laptops, en een langere bewaartermijn dan iemand bedoelde. De regels verschillen per rechtsgebied en per contract, en dit artikel is geen juridisch advies, maar de technische praktijk staat niet ter discussie: verplaats geen echte adresgegevens naar een niet-productieomgeving. Het bredere beeld, inclusief bewaring en maskering, wordt behandeld in privacy van adresgegevens.
Synthetische data haalt het dilemma weg. Het is realistisch van vorm, het is niemands adres, en het kan vrij worden gepubliceerd, gedeeld, gecommit en geregenereerd.
Hoe houd je synthetische data eerlijk?
Synthetische data veroudert. Iemand voegt een veld toe, iemand anders bewerkt met de hand een waarde om een bug te reproduceren, en binnen een paar maanden komt de fixtureset niet meer overeen met het schema dat hij hoort te testen.
Drie gewoonten vertragen die veroudering. Markeer de gegevens als synthetisch in de dataset zelf, niet alleen in een commentaar, zodat een rij zijn eigen status draagt waarheen hij ook reist. Houd een gedocumenteerde oorsprong voor de hele set bij — één generatoraanroep of één ingecheckt bestand — in plaats van herkomst per record die niemand bijwerkt. En leid de fixtures opnieuw af wanneer het schema verandert in plaats van afzonderlijke rijen te patchen, zodat de set intern consistent blijft.
Het helpt ook om het synthetische karakter zichtbaar te maken waar het ertoe doet. Een ontvangernaam of een markering in het adresblok die duidelijk niet echt is, voorkomt dat een screenshot van staging voor een echt record wordt aangezien, en voorkomt dat een testadres wordt gebruikt voor een daadwerkelijke zending door iemand die het in een log vond. De set als geheel is synthetisch: gebouwd voor softwaretesten, aan geen echte bezorgroute gebonden, en stil over iemands woonplaats.
Voor ontwikkelaars: vorm, isolatie en review
Houd fixtures in de repository als data, niet als code die data inline construeert. Waarden in een bestand zijn diffbaar, reviewbaar en grepbaar; waarden die door een keten van aanroepen in een testhelper worden gebouwd zijn geen van die dingen, en wanneer een fixture verandert ziet niemand dat in review.
Geef elk veld het type dat het productieschema gebruikt, inclusief het teksttype op postcodes. Een fixture die een postcode als getal opslaat, verbergt de voorloopnul-bug die hij hoorde te vangen, en de test slaagt om de verkeerde reden. Fixtures moeten net zo streng zijn als productie, nooit toegeeflijker.
Isoleer de gegevens per omgeving en wees expliciet over welke set waar draait. Unittests willen kleine deterministische voorbeelden; integratietests willen de scenariomatrix hierboven; staging-seeddata wil volume, gegenereerd in plaats van gekopieerd. De drie sets hebben verschillende levensduur, en ze samenvoegen is wat een seedscript onmogelijk veilig te wijzigen maakt.
Review ten slotte fixturewijzigingen als code. Een wijziging van één regel in een fixture kan stilzwijgend een falende test in een slagende veranderen, en het is precies het soort wijziging dat in een grote diff zonder uitleg aankomt.
Volgende stappen
Schrijf de scenariomatrix voor je eigen product voordat je nog een landvoorbeeld toevoegt, en verwijder de fixtures die niets testen. Genereer daarna de synthetische set in één doorgang door de adresgenerator, commit de waarden, en noteer de parameters die ze hebben geproduceerd. Als je fixtures ook telefoonnummers dragen, zijn de consistentieregels in telefoonprefixen en plaatsmatching het waard om tegelijk toe te passen. Voor het verschil tussen herformatteren en echt controleren, zie adresvalidatie en -normalisatie.