Test Driven Development – hoe Test en Dev elkaar aanvullen

Test Driven Dev_Web banner blog

Test Driven Development

Bij Test Driven Development (TDD) versterken de rollen Test en Development elkaar. Met uiteindelijk software van betere kwaliteit als resultaat. Hoe pas je Test Driven Development toe en zorg je dat de samenwerking tussen Dev en Test hierbij maximaal is?

Test Driven Development is een ontwikkelmethode waarbij eerst de unit test wordt gemaakt en vervolgens de code wordt geschreven om aan die test te voldoen. Dus ook de testers in een DevOps-team zijn betrokken bij de unit test. “Op deze manier bundel je de technische expertise van developers met de kennis van testers om de kwaliteit van code – en de uiteindelijke software – te verbeteren”, zegt Wouter Ruigrok, Agile Quality Coach bij Sogeti. “Door het toepassen van Test Driven Development breng je kwaliteit al in een vroeg stadium in en zorg je dat de kwaliteit van de code omhoog gaat.”

The devil is in the details

Bij Test Driven Development is er veel aandacht voor details. Als Mobile Developer bij Sogeti merkt Bijoya Brakenhoff dat de details in de praktijk soms vergeten worden. “Bij testen maken de details vaak het verschil. Maar deze worden wel eens over het hoofd gezien, dat is menselijk. Developers letten bijvoorbeeld veel op de acceptatiecriteria, maar minder op alle varianten die hierbij getest moeten worden. Bij Test Driven Development focussen de developers en de testers zich op andere details en dwingen ze de andere teamleden om ook daarover na te denken.”

Drie basisregels

Wil je Test Driven Development zo goed mogelijk uitvoeren? In het kort komt het neer op de volgende drie basisregels:

  1. Schrijf eerst een unit test, die zal falen omdat er nog geen code is om hem te laten slagen.
  2. Schrijf dan net genoeg productiecode om de unit test te laten slagen.
  3. Zorg dat je code weer netjes is (Refactoren).

Iteratieve cyclus

De bovenstaande cyclus van kleine stapjes herhaal je verschillende keren totdat de hele feature of story is geïmplementeerd. Vergeet hierbij zeker de refactor-stap niet. Bijoya: “Dit is het moment waarop je de code weer netjes maakt. Dat doe je pas na de geslaagde test, omdat je dan zeker weet dat iets niet zomaar om kan vallen. Maak je de code al netjes voor de geslaagde unit test? Dan schrijf je mogelijk meer code dan je nodig hebt om je doel een geslaagde test te behalen.”

Waarom Test Driven Development?

Test Driven Development stimuleert cross-functioneel gedrag. Wouter ligt toe: “Developers en testers weten van elkaar waar ze mee bezig zijn en begrijpen elkaar beter.” Daarnaast maakt deze methode het werkproces binnen een DevOps-team efficiënter. “Er zijn minder duplicate testen en er is minder rework nodig doordat je vanaf de start van het developmentproces kwaliteit inbouwt.” Uiteindelijk resulteert Test Driven Development ook in een beter softwarekwaliteit. “De code wordt beter en je weet zeker dat die niet zomaar omvalt of kapotgaat, waardoor er minder fouten ontstaan. Daarnaast wordt een deel van code gedocumenteerd, want de testen beschrijven precies wat jouw code doet.” Daarbovenop leidt Test Driven Development tot een quality mindset. “Omdat de standaard hoog ligt, zullen developers niet zo snel een quick and dirty fix doen of in de code rommelen. Zo ontstaat er een drive om de kwaliteit van de code hoog te houden.”

Meer weten over Test Driven Development?

Wat als de code van een unit test te complex is voor een tester? Hoe overtuig je developers dat ze Test Driven Development moeten toepassen en de Product Owner dat je tijd en ruimte nodig hebt om deze methode te volgen? En wat is eigenlijk het verschil tussen Test Driven Development en pair programming? In hun QX Day-presentatie gaan Ruigrok en Brakenhoff aan de hand van deze vragen nog dieper in op Test Driven Development of lees meer over de diensten rondom Quality Engineering van Sogeti.

Quality Engineering services

 

Kan ik je helpen?

Marco van Winsen Sogeti Head of Quality Engineering & Testing
Phone number: +31 886 606 600