Antwoord.

Achtergrond:

Het Arrange-Act-Assert (AAA) patroon is voorgesteld om de structuur van tests te vereenvoudigen en de leesbaarheid te verhogen. Het wordt actief gebruikt in moderne testframeworks en is de facto standaard bij het schrijven van automatische tests van elk type.

Probleem:

Zonder een duidelijke structuur worden testcases omvangrijk, moeilijk leesbaar en lastig te onderhouden. Er ontstaat verwarring tussen het voorbereiden van gegevens, het aanroepen van getest gedrag en het controleren van resultaten. Dit leidt tot accumulatie van technische schulden en fouten in tests.

Oplossing:

Strikt vasthouden aan het AAA-patroon bij het schrijven van een test.

Arrange — bereid de noodzakelijke voorwaarden, omgeving en testgegevens voor.
Act — voer de actie uit die je wilt testen.
Assert — controleer of de resultaten overeenkomen met de verwachtingen.

Belangrijke kenmerken:

Duidelijkheid in de scheiding van teststappen
Verhoogde stabiliteit en onderhoudbaarheid van tests
Vereenvoudiging van debugging en analyse van mislukte tests

Vragen met een valstrik.

Mag je de volgorde van AAA schenden als de test vanzelfsprekend lijkt?

Gewoonlijk niet. Elke afwijking van de AAA-structuur vermindert de leesbaarheid van de test voor andere ontwikkelaars en maakt deze kwetsbaar voor fouten tijdens het onderhoud.

Is het acceptabel om Act en Assert in één expressie te combineren voor korte tests?

Het is beter om dit te vermijden, omdat het het begrip en de mogelijke uitbreiding van de test in de toekomst bemoeilijkt.

Moet je logica voor gegevensopruiming (cleanup) opnemen in de Arrange fase?

Nee. Cleanup of Teardown wordt meestal geïmplementeerd met aparte methoden, bijvoorbeeld in de hooks van het testframework (After, AfterEach).

Typische fouten en anti-patronen

Het opnemen van statuscontroles in Arrange of Act
Het niet naleven van isolatie tussen tests
Het combineren van meerdere asserts die betrekking hebben op verschillende logische acties
Het ontbreken van een duidelijke scheiding tussen de stappen van de test

Voorbeeld uit de praktijk

Negatieve case

Een test voor het toevoegen van een record aan de database controleert eerst, en voegt het daarna pas toe. Een willekeurige assert in het midden verstoort dit.

Voordelen:

Snel geschreven, dekt een willekeurige bug

Nadelen:

Moeilijk te begrijpen logica van de test
Leidt tot valse fouten bij wijzigingen in de businesslogica
Onvoorspelbare volgorde van acties

Positieve case

De test begint met het opruimen van gegevens, daarna wordt er een record toegevoegd, en pas daarna wordt het resultaat gecontroleerd, strikt volgens AAA.