Antwoord

Achtergrond:

Automatisering van testen is nauw verbonden met de noodzaak om voorspelbare, reproduceerbare testgegevens te creëren en te onderhouden. Handmatige tests kunnen willekeurige gegevens gebruiken, maar geautomatiseerde scenario's vereisen nauwkeurige controle over de staat van gegevens in de database of omgeving. De schaal van toepassingen, het werken met microservices en de eisen op het gebied van privacy maken de taak van het beheren van testgegevens nog complexer.

Probleem:

Zonder beheerde testgegevens worden tests onbetrouwbaar en zijn de resultaten niet representatief. Veelvoorkomende situaties zijn:

tests falen door wijzigingen in de database
gegevens worden door meerdere tests tegelijkertijd gebruikt
er ontstaan botsingen en complexe afhankelijkheden

Bovendien kan het gebruik van echte gegevens de veiligheid of het privacybeleid schenden.

Oplossing:

Moderne benaderingen omvatten:

voorbereiding van "fixtures" (datasets die vóór de test worden geladen en erna worden verwijderd)
het genereren van unieke testgegevens on-the-fly
het gebruik van afzonderlijke testomgevingen
mocking of stubs voor externe services
het toepassen van tools voor gegevensmigratie en terugzetten (bijvoorbeeld Liquibase, Flyway)

Belangrijkste kenmerken:

mogelijkheid om de staat van de omgeving volledig te controleren
snelle herstel van gegevens naar de referentietoestand
gebruik van gespecialiseerde opslagplaatsen voor testgegevens

Vragen met een valstrik.

Kan ik echte gegevens uit de productieomgeving gebruiken voor geautomatiseerde tests?

Nee. Dit kan leiden tot gegevenslekken, schending van de voorschriften en instabiliteit van de tests door constante wijzigingen in het productie-systeem.

Is het voldoende om gewoon alle gegevens tussen tests te wissen om stabiliteit te garanderen?

Nee. Het is belangrijk niet alleen de gegevens te wissen, maar ook om ze goed voor te bereiden op de juiste staat. Bovendien kan grootschalig wissen de parallel uitgevoerde tests of services beïnvloeden.

Is het voldoende om één testomgeving voor alle teams te hebben?

Nee, dit is een weg naar botsingen en conflicten tussen tests van verschillende teams. Het is optimaal om geïsoleerde omgevingen of containerisatie (Docker test suites, ephemeral environments) te hebben.

Typische fouten en antipatronen

Automatisering "met live" gegevens
Gebrek aan schoonmaak en voorbereiding van de omgeving
Gebruik van dezelfde gegevens in parallelle tests

Voorbeeld uit het leven

Negatieve case

Het testteam gebruikte één testdatabase, waarin zowel geautomatiseerde als handmatige tests werkten. Vaak faalden geautomatiseerde tests door handmatig verwijderen of wijzigen van gegevens, wat leidde tot langdurige debug-tijd en tijdsverlies.

Voordelen:

Minimale infrastructuurkosten
Gemakkelijke toegang tot alle gegevens

Nadelen:

Onbetrouwbaarheid van tests
Veel "gebroken" omgevingen
Moeilijk om de redenen voor testfouten te analyseren

Positieve case

Het bedrijf implementeerde een infrastructuur van ephemeral-omgevingen: elke test werd uitgevoerd op een aparte kopie van de database, opgezet via Docker. Fixtures werden automatisch geladen door migratiescripts.