Test Driven Development (TDD) in een Agile omgeving

Test Driven Development kunnen we definiëren als een ontwikkelmethode waarbij ontwikkelaars alleen nieuwe code schrijven op basis van een mislukte geautomatiseerde test. Hiermee wordt met name duplicatie van code te voorkomen. De afkorting van Test Driven Development is TDD. Het primaire doel van TDD is om de code duidelijker, eenvoudiger en bovendien bug-vrij te maken.

Test Driven Development begint al met het ontwerpen en ontwikkelen van geautomatiseerde, herhaalbare testen voor iedere kleine functionaliteit van een applicatie. In de Test Driven Development methode wordt eerst de test ontwikkeld die specificeert en valideert wat de code moet doen.

TDD is het omgekeerde ontwikkelproces

In het normale ontwikkelproces programmeren we eerst de programmacode en die we vervolgens testen. Bij TDD beginnen we met testen die vervolgens fout lopen omdat we ze al vóór de ontwikkeling uitvoeren. Om de test te halen, moet het ontwikkelingsteam dus de code ontwikkelen en telkens uitbreiden.

Het eenvoudige concept van Test Driven Development is testen te ontwerpen en uit te voeren voordat nieuwe code wordt geschreven. Het schrijven van dubbele code voorkomen we hiermee. Dit komt omdat we slechts de kleinste hoeveelheid programmacode schrijven, die genoeg is om een test te doen slagen. Als de kleine test geslaagd is loopt het testproces op de volgende foutmelding waarvoor we dan weer code moeten schrijven. Deze cyclus gaat dus door totdat de test foutloos wordt doorlopen. Feitelijk zijn de tests niets anders dan de requirements van de applicatie waarvan we moeten vaststellen of er aan is voldaan.

Test-driven ontwikkeling is een proces van het ontwikkelen en uitvoeren van geautomatiseerde tests voor de daadwerkelijke ontwikkeling van de applicatie.

TDD is een iteratief test gedreven ontwikkelproces

Test Driven Development is dus een iteratief ontwikkelingsproces dat tot de Agile familie van methodes behoord. TDD komt dan ook meestal tegen in een Agile omgeving. Iedere iteratie begint met een reeks testen die zijn geschreven voor een nieuw stuk functionaliteit. Al in de eerste fase vinden de testen plaats. In de volgende fase van de iteratie schrijven we de toepassingscode met de bedoeling alle testen van de iteratie foutloos te doorlopen. Zodra de toepassingscode gereed is, voeren we testen uit.

Eventuele fouten in de testrun worden vastgelegd en er wordt meer programmacode geschreven en opnieuw verwerkt om de testen wel te laten slagen.

Voordelen van Test Driven Development

1. De unit- of moduletest toont aan dat de code echt werkt.
2. De test stuurt het ontwerp van het programma.
3. Hertesten maakt het mogelijk het ontwerp te verbeteren.
4. Regressie-testen blijven echter klein van omvang.
5. De kosten van een groot aantal bugs voorkomen we bovendien.

Nadelen van Test Driven Development

1. De test kan gericht zijn op de validatie van de code en niet op wat de code echt zou moeten doen.
2. Testen wordt een onderdeel van de onderhoudskosten van een applicatie.
3. Ontwikkelaars kunnen het ervaren als een tijdverspilling.
4. De test moeten worden herschreven als de requirements wijzigen.

Ontwikkelfasen

Als je TDD als ontwikkelmethode omschrijft zijn de volgende fasen te onderkennen:

Fase 1: Behoeftedefinitie

In fase 1 verzamelen we de applicatie requirements en leggen die vast.

TDD begint met het definiëren van requirements in termen van testcases. De requirements leggen we gedetailleerd vast.

Deze lijst met tests werken we voor iedere requirement uit. Vervolgens worden in fase 1 de testcases voor alle requirements geschreven.

Bij de eerste test is er helemaal nog geen code aanwezig, wat een compilatiefout opleverd. Dat is het enige doel van het schrijven van de eerste test. Dit dwingt de ontwikkelaar om alleen die code toe te voegen die nodig is.

Fase 2: Testen uitvoeren

In deze fase proberen we gewoon om de testen uitvoeren.

Als een test voor de eerste keer wordt uitgevoerd, krijgen we een foutmelding. Deze fout geeft duidelijk aan dat de code voor deze functionaliteit niet aanwezig is.

Fase 3: Programmacode toevoegen / herschrijven

Na het mislukken van de test in fase 2, zal de ontwikkelaar een logische stap  ondernemen en de gewenste code toevoegen.

Met deze wijziging gaan we terug naar fase 2 waarin de testen opnieuw worden uitvoert. Benieuwd naar het testresultaat dat we deze keer krijgen.

Deze test loopt waarschijnlijk fout omdat er een fout in de programmacode zit. Op basis van deze testfout past de ontwikkelaar de code net genoeg aan om de test goed te doorlopen. Ondertussen zijn we alweer in fase 3 teruggekeerd. Nu kunnen we de testen van fase 2 weer uitvoeren. De testresultaten na deze verandering moeten aantonen of de code nu wel werkt. Zodra alle testen zijn geslaagd is de conclusie dat de iteratie is voltooid.

Functies toevoegen

Als er meer functies zijn die we in de applicatie moeten implementeren, zal de applicatie dezelfde fasen opnieuw doorlopen. Deze keer met nieuwe functies en nieuwe testen. Het toevoegen van nieuwe functies kan echter tot gevolg hebben dat we eerder goed geteste code moeten aanpassen. De applicatie gaat zich namelijk anders gedragen. Dit betekent in TDD dat we eerst testgevallen maken om het nieuwe wenselijke gedrag vast te stellen. Als dit niet het geval is wijzigen we de code en testen we opnieuw.

Discussieer mee op LinkedIn.