Ontwikkeltijd besparen door Test Driven Development
4

We zien steeds meer organisaties met test-driven-development de kwaliteit van hun software en architectuur verbeteren. Helaas merken we ook dat er nog veel misverstand is over de meerwaarde van test-driven-development. Dit is jammer, omdat het toepassen van TDD een unieke kans geeft om de onderhoudskosten van uw software te verlagen en de levensduur te verlengen.
Test Driven Development

Dit komt vooral omdat het handmatig testen van een applicatie bij continue ontwikkel effort steeds meer tijd zal vragen en op termijn niet houdbaar is:
Een groot misverstand is dat het schrijven van geautomatiseerde unittesten iets extra’s is dat een ontwikkelteam moet doen en dat het dus meer tijd zal kosten. Het is niet moeilijk om aan te tonen dat unittesten zich op termijn terugverdienen. Maar alleen degene die de techniek hebben toegepast zullen durven te beweren dat het toepassen van testen hun al tijdens het
ontwikkeltraject tijd bespaard heeft. Laat me dit uitleggen aan de hand van de werkelijke meerwaarde van geautomatiseerde unittesten.
Test Driven Development

Acceptatie criteria en scenario’s
Om een functionaliteit te ontwikkelen moet worden nagedacht over scenario’s en acceptatiecriteria. Dit is iets wat een scrum team sowieso moet doen en over het algemeen wordt het toch als meerwaarde gezien om deze criteria ergens te borgen. Wat is een betere plek om deze informatie te borgen, dan in de vorm van een test bij de code.

Architectuur
Ieder team zal moeten nadenken over de architectuur van de software. De eisen die geautomatiseerd testen aan de software stellen, zijn precies in lijn met de best-practices van het ontwikkelen van goede software. Wilt u dat een team de principes van SOLID en loose coupling toepast: laat het team automatische testen schrijven en ze kunnen niet anders.

Korte feedback loops
Het proces van test-driven-development gaat niet alleen om het verkrijgen van werkende code (een groene test), maar borgt dat een team de code continue verbetert (“refactoring”). Dit komt de leesbaarheid en begrijpelijkheid van de code ten goede en maakt het veel gemakkelijker om de code verder uit te breiden naarmate het project vordert.

Minder debuggen
Wanneer code gemaakt wordt zonder testen, is de enige manier voor een ontwikkelaar om te verifiëren dat de code functioneert, handmatig de applicatie te debuggen. Bij geautomatiseerde testen, doet de test dit werk voor de ontwikkelaar op een veel fijnmazigere manier waardoor de tijd die de ontwikkelaar in de debugger moet besteden drastisch verminderd. Ik ben zelf in projecten actief geweest waar de debugger er alleen nog aan te pas kwam om een laatste controle uit te voeren en dat heeft me vele uren bespaard.

Kleine bouwstenen
Bij het coderen van de componenten met het unit-testen in het achterhoofd wordt de ontwikkelaar gestimuleerd in kleine stapjes te denken. Hiermee blijven methoden en klassen klein. Op deze manier wordt de code leesbaar en onderhoudbaar.

Auteur: Menno Jongerius / Bergler Competence Center © 2015