Bij Test Driven Development denkt men vaak dat het testen van je code het doel is, omdat het woord “Test” zo prominent vooraan staat in de term.
Apart discipline
Testen is een andere discipline dan het schrijven van software. Je gebruikt andere libraries, andere concepten en vaak moet je dingen meer vanaf de buitenkant observeren, terwijl bij het schrijven van software je dingen veel meer vanuit de binnenkant benadert. Naast de kennis van tools en technieken, moeten de testen natuurlijk ook geschreven worden, onderhouden worden en draaien op een geautomatiseerde wijze.
Maar goed, dit is dan ook het grootste gedeelte van de kosten-zijde van TDD.
De voordelen
Aan de andere kant zijn er heel wat voordelen die noemenswaardig zijn:
- Vertrouwen. Door de tests weet je dat alles werkt zoals de bedoeling is. Hierdoor is het voor mensen in het team sneller om de code te begrijpen, omdat de juiste testen aangeven wat de functie achter de code is. Ook is het herstructureren van de code minder ‘eng’, want de testen borgen de functionaliteit.
- Nadenken. Doordat je moet beginnen bij het gewenste eindresultaat wat je wil testen, begin je ook meteen met de juiste vragen te stellen: Wat verwacht je eigenlijk van de code? Welke feedback krijgt de gebruiker op zijn acties? Welke niet-succes scenario’s zijn er te bedenken?
- Documentatie. Omdat je langer blijft ‘hangen’ in het denkprocess en niet meteen code gaat schrijven, denk je vaak in grotere lijnen over de oplossingen en de weg er naartoe. Een perfect moment om dit op te schrijven als documentatie.
- Beter scheiden van verantwoordelijkheden. Je wil niet in elke test een super grote ‘setup’ stap hebben, dus je gaat de verantwoordelijkheden beter definiëren. Moet mijn functie deze informatie wel krijgen? Is minder niet beter? Functies worden scherper en makkelijker te testen en ook makkelijker om over te redeneren. Kortom het opzetten van architectuur is makkelijker!
- TODO lijst. Omdat je al een goed beeld hebt wat een onderdeel van je systeem moet gaan doen, kan je een ‘outline’ maken van je testen, wat direct als een Todo lijst werkt. Je werk is meteen wat gestructureerder en ook de voortgangsrapportage is makkelijker.
- Verkenning. Soms weet je simpelweg nog niet wat voor code je moet schrijven. Of je teveel schrijft, het probleem overdenkt, etc. Door middel van tests definieer je wel al je einddoel, waardoor er naartoe navigeren makkelijker is. En je ook nooit teveel code schrijft!
Baten vs kosten
Zo zie je dat de baten de kosten zwaar overtreffen. Toch maakt het niet meteen testen makkelijk. Het vergt aandacht, discipline en tijd. Maar als je eindproduct er robuuster van wordt, de tijd om uit te rollen korter wordt, de codebase beter te onderhouden is en begrijpelijker wordt (wat helpt bij onboarden van nieuwe teamleden), dan is het niet echt een discussie 🙂
