Test-driven development

Test-driven development (TDD) is een ontwikkelmethode voor software waarbij eerst tests worden geschreven en daarna pas de code. De naam test-driven development komt van Kent Beck, die deze techniek in 2002 op papier heeft gezet en daarmee de bekendheid ervan vergroot heeft. Het valt onder de agile-softwareontwikkeling.

Ontwikkelcyclus

De ontwikkelcyclus hieronder is gebaseerd op het boek Test-driven development by example van Kent Beck. Deze cyclus kan zo vaak herhaald worden als nodig is om de code volledig werkend te krijgen volgens de requirements.

1. Test maken: In test-driven development maakt de programmeur eerst een test, gebaseerd op een requirement, en schrijft pas dan de code.
2. Alle tests draaien en kijken of de nieuwe test faalt: Deze test moet initieel in principe falen, aangezien het stuk code waarop deze test van toepassing is nog niet bestaat. Het laten falen van de nieuwe test is belangrijk om na te gaan of de test effectief is (geen fouten bevat en daardoor bijvoorbeeld altijd slaagt).
3. Code schrijven: In deze stap wordt de daadwerkelijke code geschreven om de zojuist gemaakte test te laten slagen. Deze code mag alleen functionaliteit bevatten die nodig is om de test te laten slagen. De code hoeft niet perfect geschreven te zijn, zolang deze maar werkt. In een latere stap zal de code nog herschreven worden volgens de standaard.
4. Tests draaien en kijken of deze slagen: In deze stap draaien alle tests nogmaals en wordt gekeken of alle tests slagen. Is dit het geval dan is dit een goed uitgangspunt om aan de volgende stap te beginnen.
5. Code herschrijven: In deze stap wordt de code opgeschoond en volgens de standaard herschreven. Ook zal eventuele dubbele code, nodig om de onderlinge afhankelijkheid van de componenten te minimaliseren, verwijderd worden.

Voordelen

• Er wordt bij test-driven development gekeken vanuit het perspectief van de gebruiker. De testcases waarvoor de code wordt geschreven zullen namelijk gebaseerd zijn op de requirements, die vanuit het oogpunt van de gebruiker zijn opgesteld. Problemen met de bruikbaarheid van de interface kunnen zo eerder worden gevonden en gecorrigeerd in een stadium waarin dat het gemakkelijkst is.
• Er wordt specifiek gelet op de requirements, aangezien de tests daarop gebaseerd zijn. Extra, wellicht overbodige, functionaliteiten zullen hierdoor niet geïmplementeerd worden, waardoor de hoeveelheid programmacode binnen de perken blijft.
• Doordat alle code van het begin af aan wordt getest, wekt dit meer vertrouwen bij het ontwikkelteam en bij de klant.
• Ondanks de extra code die nodig is voor het schrijven van de tests, zal de ontwikkelingstijd toch korter worden, aangezien fouten al in een zeer vroeg stadium gevonden zullen worden.
• Aangezien alle onderdelen van de code los van elkaar getest worden is de onderlinge afhankelijkheid kleiner en daarom minder complex.

Nadelen

• De programmeur schrijft bij deze methode zowel de tests als de code voor de applicatie. Dit heeft tot gevolg dat wanneer de programmeur iets over het hoofd ziet, dit in zowel de test als in de code over het hoofd gezien zal worden.
• Wanneer er een groot aantal tests succesvol is, kan dit de indruk geven dat de applicatie volledig getest is. Een valkuil is dat een integratie- en systeemtest niet of nauwelijks uitgevoerd worden.

Toepassing

Deze methode kan goed gecombineerd worden met extreme programming (XP), aangezien XP ook gebruikmaakt van korte ontwikkelcycli met continu testen van de software.