Stop met rommeldata! Begin met testdata waar je op kunt bouwen

Flaky testautomatisering: voor veel teams is het dagelijkse realiteit. Tests die de ene dag falen en de andere dag slagen, zonder duidelijke reden. Automatisering die eerder frustratie oplevert dan vertrouwen.

‍

Die instabiliteit kan verschillende oorzaken hebben. Soms ligt het aan je systeem-under-test, bijvoorbeeld door veranderende functionaliteit of instabiele omgevingen. Maar net zo vaak zit het probleem in je eigen testframework: hoe tests zijn opgezet, welke aannames je doet over testdata en hoe je omgaat met afhankelijkheden tussen tests.

‍

Juist dat laatste willen we in deze blog verkennen. Want dáár heb je directe invloed op. Hoe voorkom je flaky tests door geautomatiseerde testen betrouwbaar én onderhoudbaar op te zetten? Binnen SPARTA doen we dat door het toepassen van de FIRST-principes. Die maken tests betrouwbaarder. We maken ze daarnaast onderhoudbaar en leesbaar met behulp van builder patterns en directors. Zijn deze termen nieuw? Later in deze blog lees je er meer over.

‍

Oorzaken van flaky testen

Je herkent het misschien wel. Een test die op maandag succesvol draait en op dinsdag niet, zonder dat iemand iets heeft aangepast. Tests die lokaal prima slagen, maar in de pipeline falen. Of tests die alleen slagen wanneer ze voor het eerst op een lege omgeving draaien, maar daarna niet meer. Dit zijn typische voorbeelden van flaky tests.

‍

In veel gevallen is flakiness te herleiden tot een gebrek aan structuur of isolatie in je framework. Het zit vaak niet in de test zelf, maar in de manier waarop de test gebruikmaakt van testdata. Denk bijvoorbeeld aan:

• Tests die afhankelijk zijn van elkaars data of uitvoeringsvolgorde, waardoor ze niet onafhankelijk kunnen draaien
• Testdata die in de omgeving blijft staan en resultaten van andere tests beïnvloedt
• Tests die slagen of falen op basis van toevallige data, waardoor resultaten niet reproduceerbaar zijn

Het gevolg: geautomatiseerde tests zijn niet betrouwbaar. Ze geven wisselende resultaten, zijn lastig te debuggen en kosten meer tijd dan ze opleveren.

‍

FIRST als fundament voor betrouwbare testautomatisering

Om tests betrouwbaar te maken, moeten ze voorspelbaar uitvoerbaar zijn. Elke keer opnieuw, onafhankelijk van volgorde of context. Daarom gebruiken we binnen SPARTA het FIRST-model als toetssteen. FIRST staat voor:

• Fast: tests moeten snel draaien en snelle feedback geven
• Independent: tests mogen niet afhankelijk zijn van andere tests
• Repeatable: elke test moet consistent hetzelfde resultaat geven
• Self-validating: het moet meteen duidelijk zijn of een test slaagt of faalt
• Timely: tests moeten op het juiste moment draaien om waardevol te zijn

‍

Vooral Independent en Repeatable zijn cruciaal om flakiness te voorkomen. En dat begint bij testdata: binnen elke test wil je testdata opbouwen, gebruiken én opruimen als dat nodig is. Maar hoe doe je dat zonder dat onderhoud een last wordt?

‍

Onderhoudbare testdata maken met het Builder Pattern

Als je testdata in elke test afzonderlijk wilt aanmaken, dan wil je dat slim aanpakken. Binnen SPARTA gebruiken we hiervoor het Builder Pattern. Het is een beproefde ontwerpaanpak uit de softwareontwikkeling en helpt om stap voor stap gestructureerde objecten op te bouwen. Wij passen dit principe toe op testdata.

‍

Een builder laat je precies die data opbouwen die je voor een test nodig hebt, zoals een klant, een polis of een gebruiker. Die data laad je direct in je systeem-under-test. Na afloop ruim je de data weer op als dat nodig is.

‍

Dit maakt tests niet alleen herhaalbaar, maar ook leesbaar. De code voor datageneratie en teststappen staat bij elkaar. Zo zie je in één oogopslag welke data bij de test hoort en waarom. Dat ontbreekt vaak bij tests die afhankelijk zijn van centrale dataloads, zoals nachtelijke jobs die grote batches in de testomgeving zetten. Daarbij heb je als tester weinig zicht op welke data wordt gebruikt of wanneer die is aangemaakt. Met builders koppel je data direct aan de test waarvoor deze bedoeld is.

‍

Een eenvoudig voorbeeld

Stel, je wilt in een test een klant aanmaken. Zo’n klant bestaat waarschijnlijk uit een combinatie van eigenschappen: voornaam, achternaam, adresgegevens, woonplaats, inkomenssituatie, leeftijd, misschien zelfs gezinssamenstelling of type dienstverband.

In een traditionele test definieer je de persoon misschien op de volgende wijze:

Wees eerlijk. Zie jij het verschil? Spoiler: het is inActive. Overzichtelijk is dit natuurlijk niet. Hierdoor is het ook niet duidelijk welke testdata exact relevant is voor de test. Vergelijk dit nu eens met de volgende code:

Dit is een Builder in actie. Nu is de code wel overzichtelijk. Het genereert een klant, inclusief de standaard-NAW-gegevens en overige kenmerken. Deze hoef je echter niet expliciet op te geven, zoals in de vorige voorbeelden. Dit gebeurt automatisch en ‘buiten beeld’, zodat deze code niet terugkomt in je test.  Vervolgens geef je specifieke waarden mee die wel specifiek zijn voor de test die je uitvoert. Dat maakt je test heel leesbaar.  

‍

Hier een schematische weergave hoe een Builder werkt:

Door builders te combineren met libraries zoals Faker, genereer je bovendien altijd synthetische testdata die volledig AVG-proof is. En omdat je met vaste parameters werkt, blijft je klant ook echt 35. Zelfs als je de test 5 jaar achter elkaar draait. Wel zo veilig en betrouwbaar.

‍

‍Complexere situaties

Voor complexere situaties gebruiken we directors. Dit zijn herbruikbare scripts die met behulp van meerdere builders complete scenario’s opbouwen.

‍

Stel dat je wilt testen dat een klant al meerdere diensten heeft afgesloten en net een nieuwe aanvraag indient. In plaats van dat scenario handmatig op te bouwen, gebruik je één duidelijke instructie: een director. Achter de schermen worden meerdere builders aangeroepen,voor de klant, voor de diensten en voor de nieuwe aanvraag. Terwijl je testcode zelf overzichtelijk blijft.

‍

Zelf aan de slag met FIRST en Builders?

Betrouwbare testautomatisering begint bij de juiste principes. Door FIRST serieus te nemen en testdata slim op te zetten met builders en directors, maak je tests niet alleen stabieler, maar ook beter leesbaar en makkelijker te onderhouden.

‍

In onze workshop “Testdata opzetten met het Builder Pattern” leer je precies hoe dat werkt. Je ziet hoe je domeinspecifieke data opbouwt, hoe je tests herhaalbaar maakt en hoe SPARTA dit ondersteunt met een robuuste architectuur.

‍

Nieuwsgierig? De workshop werd onlangs gegeven op TestNet en is nu beschikbaar voor teams die testautomatisering structureel willen verbeteren. We vertellen je er graag meer over.

‍

‍