Test driven development (TDD), is een manier van software ontwikkelen waarbij code wordt geschreven op basis van een test. Op deze manier zorg je ervoor dat jouw code continu wordt getoetst. In dit artikel krijg je inzicht in hoe test-driven development werkt en wat de voor- en nadelen zijn.
Hoe werkt Test-Driven Development?
Kent Beck, de bedenker van test-driven development, legt het aan de hand van 5 stappen uit. Deze 5 stappen kun je eindeloos doorlopen om zo jouw code werkend te krijgen.
- Je begint door een test te maken die gebaseerd is op een requirement. Deze requirement kun je verkrijgen uit een user-story.
- Draai een test en kijk of hij faalt. Het klinkt vreemd, maar hij moet falen aangezien je er nog geen code aan gekoppeld hebt.
- Schrijf je code. Nu begin je met code schrijven die binnen die test valt. Dit houdt in dat je uitsluitend bezig gaat met de functionaliteit zodat die test slaagt. De code hoeft niet perfect te zijn, zolang het maar werkt.
- Draai de tests. Als alle tests goedgekeurd zijn is het tijd om naar stap 5 te gaan.
- Code opruimen. Hier maak je je code schoon. Is er sprake van dubbele code, wat nodig is om de afhankelijkheid van de componenten te minimaliseren, dan kun je die verwijderen.
De voordelen
Ten eerste schrijf je een test op basis van een user story. Dit houdt in dat je in een vroeg stadium problemen in de bruikbaarheid van jouw app kunt vinden. “Stel dat de app een mail moet versturen nadat een gebruiker zich heeft geregistreerd,” legt Sjors Ottjes, developer, uit. “dan wil je niet dat je handmatig moet controleren of die mail is verstuurd. Door hiervoor een test te schrijven, weet je altijd of deze functie werkt.” Een tweede voordeel is dat je vanaf het begin alle code test. Dit geeft meer vertrouwen bij je development team en jouw gebruiker. Ten derde verkort je zo ook de ontwikkelingstijd, ondanks dat je meer code schrijft, omdat je fouten in een vroeg stadium vindt. Het vierde voordeel is dat je minder regressie hebt. Dit omdat je hier ook continu voor test. Ten laatste zorgt het schrijven van tests er voor dat de complexiteit van de uiteindelijke code lager is waardoor er makkelijker mee valt te werken en componenten gemakkelijker herinzetbaar zijn. Complexe componenten, bijvoorbeeld componenten met veel verantwoordelijkheden of veel afhankelijkheden, zijn moeilijk testbaar. Door het lostrekken en versimpelen van deze componenten maak je ze zowel beter testbaar, als ook minder complex.
De beperkingen
Er zijn enkele beperkingen die je in het achterhoofd moet houden, wanneer je eenmaal bezig gaat met test-driven development. Ten eerste zijn tests alleen bruikbaar in je eigen testomgeving, en zijn ze niet bruikbaar met externe factoren zoals API’s van andere bedrijven. Als die plotseling veranderen, dan zal het alsnog in de productieomgeving spaak lopen. Met andere woorden, je kunt calls naar een API’s wel nabootsen maar wanneer de applicatie eenmaal live gaat, kun je hiervoor geen tests meer doen. Ten tweede zijn tests lastig om correct te schrijven. Dit probleem komt vooral voor als je meer gaat doen dan unit testing. Ten derde ben je in de startperiode vaak trager met het ontwikkelen van je project, maar de tijd die je extra neemt in het begin, betaalt zich later wel terug. Ten laatste is het vaak het geval dat er veel misverstanden zijn over TDD waardoor ontwikkelaars het niet willen leren. Daarom is het zaak om het hele team goed te informeren en enthousiast te krijgen over test-driven development zodat het succesvol kan worden uitgevoerd.
Test-Driven Development voor bedrijven
Wanneer programmeurs, zowel in-house, als ook bij een maatwerk leverancier van software, werken volgens de principes van TDD zijn er vele voordelen. Met test-driven development wordt er namelijk altijd gestreefd naar het leveren van software met minder fouten. Ook zorgt TDD ervoor dat er gericht gewerkt wordt aan vastgestelde requirements en dat het eindresultaat een hogere efficiëntie heeft. Dit zorgt er al met al voor dat je aan het eind van de rit met een beter product zit.