Test Driven Development: vakantie voor de tester!

In veel software ontwikkeltrajecten komt testen aan het eind van een oplevering. In scrum omgevingen wordt testen zelfs vaak bij de ontwikkelaars gelegd. De term ‘multifunctioneel team’ maakt dat de klant of werkgever ervan uitgaat dat de ontwikkelaars de tests ook wel kunnen uitvoeren. Met of zonder tester erbij, in scrum of stiekem toch traditioneel gestuurde projecten gaat het vaak als volgt: “Bijna klaar voor productie, o ja, nog even testen”. En (tussen de regels door): “zorg vooral dat je niet te grote issues vindt want aan de klant is beloofd dat we morgen opleveren.”

Een goed testproces is essentieel voor de kwaliteit. En kwaliteit kost tijd. Op den duur levert het geld op, maar op de korte termijn heeft het vaak geen prioriteit.

Het staartje van elk traject.

Zo niet bij Test Driven Development. In deze filosofie komt testen aan kop. Zonder test geen code, hoorde ik onlangs iemand betogen over TDD. Een uitgangspunt waar veel testers alleen maar van dromen. Het mooie van deze filosofie is dat de ontwikkelaars de tests zelf schrijven. Het gaat namelijk over unit tests die de werking van de code op het laagste niveau valideren.

• Run de bestaande tests (als ze er zijn; bij de eerste run heb je nog niets) en kijk of ze allemaal slagen.
• Voeg een nieuwe test toe die het stukje code test dat je nog gaat toevoegen.
• Run de tests nog een keer, en valideer dat de nieuwe test faalt.
• Voeg vervolgens het nieuwe stukje code toe.
• Valideer dat de nieuwe test slaagt (en de bestaande tests ook nog steeds).

1. Welke unit tests moeten worden gemaakt?

In de praktijk blijkt dat als TDD wordt toegepast, dit niet zo nauwgezet wordt gevolgd als hierboven beschreven. Dat toch niet alle code vooraf wordt gegaan door een test. Dan moet er gekozen worden welke code een test krijgt en welke niet. Dit kan het beste bepaald worden door te kijken naar de business waarde van dat deel van het systeem. De product owner moet bepalen, met het team (inclusief de tester) als belangrijke adviseur, welke onderdelen van de software zoveel toegevoegde waarde hebben dat tests echt onontbeerlijk zijn. Dat betekent dat er ook bepaald wordt welke onderdelen zonder tests mogen bestaan. Als de tests daarna volgens die strategie geïmplementeerd zijn, is het nodig dat de tester regelmatig monitort of de tests inderdaad de afgesproken delen van het systeem nalopen.

2. Wat doen de unit tests eigenlijk?

Daarnaast moeten de tests zélf ook getoetst worden. Het hebben van een test voor de belangrijke stukken code is niet genoeg. Een test kan ook een foutje bevatten, het kan bijvoorbeeld voorkomen dat de test altijd een 'OK' uitkomst meegeeft, of iets doet of meet dat de werking van de code helemaal niet verifieert. De tester moet het team helpen door mee te kijken en vragen te stellen over wat de tests doen.

3. Wat moet het systeem als geheel eigenlijk doen?

Volgens de wellicht ouderwetse waterval-aanpak moet op elk niveau de juiste test worden uitgevoerd. Bij het schrijven van de code zijn dat unit tests, daarna komen keten- of integratietests en dan zijn er nog de end-to-end tests. Als je test driven ontwikkelt, kun je er weliswaar vanuit gaan dat de gebouwde componenten goed zijn, maar blijft het nodig ketentests te doen. Deze ketentests testen de integratie tussen de componenten; werken de componenten ook daadwerkelijk samen om de gewenste werking van het systeem als geheel te bereiken? Met de end-to-end tests, die daar dan weer boven hangen, loop je de gebruiker-gedreven scenario’s af, in de UI van het systeem. Hiermee kijk je of het systeem aan de verwachtingen voldoet die in de user story zijn geschetst.

Het bounty-eiland laat nog even op zich wachten, maar is een stukje dichterbij gekomen.

Ik dank collega Daniël voor zijn blik vanuit de praktijk en de opbouwende discussies die we samen over dit onderwerp hebben gevoerd.