Kernpunten
- Gebruik vormgetrouwe gegevens, geen echte klantrecords.
- Combineer vaste fixtures met reproduceerbare variatie.
- Houd testdata weg uit productieprocessen.
Auteurschap en beoordeling
Redactionele principes- Geschreven door
- RZTKB Editorial Team
- Beoordeeld door
- RZTKB Data Review
- Laatste inhoudelijke update
- 2026-08-28
Waarom productieadressen geen handige fixture zijn
Een gekopieerd klantrecord belandt al snel in logs, screenshots en gedeelde testtools. Dat is onnodig. Voor de meeste tests zijn alleen veldlengte, tekens, regionale samenhang en foutafhandeling van belang. Die eigenschappen kun je zonder persoonsgegevens modelleren.
Kies gevallen die iets bewijzen
Maak een adres zonder toevoeging, één met lettertoevoeging, een lange straatnaam en een postcode met spatie. Houd woonplaats en postcode bij elkaar. Als een test faalt, weet je dat het formulier fout zit en niet de voorbeelddata.
Vaste fixtures en seeds
Regressietests vragen om dezelfde invoer bij elke run. Bewaar een klein, beoordeeld setje vaste records. Voor verkennende tests kun je een generator gebruiken, maar log de seed zodat een fout opnieuw kan worden opgebouwd.
Zet een harde grens rond testdata
Markeer records als test en blokkeer ze in verzending, betalingen en identiteitscontrole. Maak duidelijk dat een openbare locatie geen bewijs van bewoning is.
Veelgestelde vragen
Is een willekeurig adres altijd verzonnen?
Niet per se; een openbare locatie kan bestaan, maar stelt geen bewoner voor.
Kan ik hiermee postcodevalidatie testen?
Ja, voor vorm en veldgedrag.
Hoeveel fixtures zijn genoeg?
Een klein kernsetje plus gerichte randgevallen.
Mag testdata naar een vervoerder?
Alleen in een expliciete sandbox zonder echte zending.