Antwoord.

De implementatie van testfixtures is een cruciaal aspect van automatiseringstests, dat zorgt voor de voorbereiding van de omgeving, gegevens en afhankelijkheden voor testscenario's.

Achtergrond Fixtures zijn ontstaan in geautomatiseerde testing als een manier om centraal het voorbereiden en schoonmaken van de omgeving te beheren voordat de tests worden uitgevoerd. Hiermee bereiken teams consistentie en voorspelbaarheid van tests, wat vooral belangrijk is bij voortdurende codewijzigingen.

Probleem Zonder goede fixtures worden automatiseringstests onbetrouwbaar, zijn ze van elkaar afhankelijk, verstoren ze elkaar bij gelijktijdige uitvoering en vergroten ze de technische schuld (omdat de setup/teardown logica gedupliceerd en uitgebreid raakt).

Oplossing Gebruik standaardmechanismen voor fixtures die door testframeworks worden aangeboden (bijvoorbeeld @BeforeAll, @BeforeEach in JUnit of conftest.py in pytest). Probeer fixtures aanpasbaar en geïsoleerd te maken:

Laad en verwijder alleen wat echt nodig is voor de test;
Voor complexe gevallen passen we dynamische creatie van gegevens/objecten toe met daaropvolgende opruiming;
Houd het grootste deel van de voorbereidingscode op één plek;

Belangrijke kenmerken:

Isolatie van de omgeving voor elke test;
Minimalisering van afhankelijkheden tussen tests;
Centralisatie en schaalbaarheid van fixtures.

Vragen met een valstrik.

Mag je in één test de objecten die door de fixture zijn gemaakt, wijzigen als ze nodig zijn voor volgende tests?

Nee, dat zou de tests afhankelijk maken: wijzigingen aangebracht door één test kunnen een andere breken. Het is beter om nieuwe objecten voor elke test te gebruiken of wijzigingen terug te draaien na elke uitvoering.

Waarom zouden we de hele database niet "eenmaal en voor altijd" aan het begin van de testuitvoering laden om het proces te versnellen?

Een dergelijke benadering kan leiden tot onbetrouwbare tests en moeilijk te vinden bugs. Gegevens kunnen tussen tests "vastlopen", en de volgorde van uitvoering wordt kritiek.

Mag je één globale fixture voor de hele set tests gebruiken?

Nee, globale fixtures zijn alleen toegestaan voor volledig onafhankelijke tests. Deze aanpak leidt meestal tot wederzijdse invloed tussen de tests, wat de analyse en ondersteuning bemoeilijkt.

Typische fouten en anti-patterns

Gebruik van globale/onreinigbare fixtures
Duplicatie van de logica voor gegevensvoorbereiding in elke test
Onreinigbare testgegevens die de omgeving "vervuilen"

Voorbeeld uit het leven

Negatief geval

In het project werd besloten om tijd te besparen en automatiseringstests op één database uit te voeren, zonder wijzigingen terug te draaien na elke test. Na de introductie van tests die dezelfde gegevens wijzigden, verschenen er flakey errors: tests faalden soms één voor de ander, afhankelijk van de volgorde van uitvoering.

Voordelen:

Snelle uitvoering (in theorie)
Minder code voor opruiming

Nadelen:

Moeilijkheden bij het vinden van de oorzaken van fouten
Tests zijn van elkaar afhankelijk
Schaalbaarheidsproblemen

Positief geval

Gebruikten fabriek-fixatures: elke test creëert zijn eigen gegevens, verwijdert deze na voltooiing. Oude bugs worden niet meer gereproduceerd, de volgorde van de tests is niet belangrijk.