Test-driven development (TDD) wilt zeggen dat er een geautomatiseerde test wordt geschreven alvorens iemand start met de werkelijk functionaliteit te programmeren.
Hierbij wordt net afdoende code geschreven om de test te laten slagen, waarna de code refactored wordt teneinde de leesbaarheid te vergroten en eventuele fouten er uit te halen. Dit is vervolgens een repetitive cycle.
Reflecties op test-driven development:
- TDD is doorgaans lastig. Het duurt een tijd voordat de programmeur het doorgrond. Het is zelfs zo dat in veel gevallen het niet helpt om de begeleiden en te demonstreren. Het helpt meer om een programmeur te laten pair-programmen met een programmeur die het concept goed begrijpt. Wanneer een programmeur het begrijpt, wil de programmeur zelden meer op een andere manier te werk gaan.
- TDD heeft een substantieel effect op het systeemdesign
- Het neemt tijd in beslag voordat TDD opgezet is en effectief kan draaien in een nieuw product, vooral in een black-box integratie test. De ROI (return on investment) is echter erg snel/hoog.
- Het is noodzaak dat er afdoende hulpmiddelen beschikbaar zijn om eenvoudig testen te schrijven. Dit betekent dat er voldoende hulpmiddelen beschikbaar dienen te zijn, dat mensen opgeleid zijn om met TDD te werken en bijvoorbeeld de juiste base-classes aan te leveren en dergelijke.
TDD wordt door de schrijver altijd toegepast binnen nieuwe code, er is vervolgens geen excuus om geen TDD te gebruiken. In oude code wordt het gebruik van TDD aanzienlijk lastiger gemaakt. Soms kan dit wel, soms ook niet.
Reageer op dit bericht