Tag test-driven development
Tests als ontwerpmiddel
Tests zijn een ontwerpmiddel, een design tool. Ze fungeren als indicator voor de kwaliteit van het ontwerp van je code. De vuistregel is even eenvoudig als zag-het-niet-want-het-stond-recht-voor-mijn-neus-vanzelfsprekend: Is het moeilijk om er een test voor te schrijven? Dan deugt het ontwerp niet!
Test-driven development is een ontwerpdiscipline
Een collega benaderde me laatst met een vraag over een stuk code. Hij was bezig met het implementeren van een feature om een toets met afbeeldingen om te zetten naar een PDF-representatie ervan. Zijn vraag was: hoe kom ik aan die afbeelding? Of liever: waar kom ik aan die afbeelding? Zijn eerste ingeving was om via dependency injection de relevante repository mee te geven aan de ImagePdfGenerator. - Het is een klassiek geval van het verknopen van het ophalen van data en het manipuleren ervan. Ik bleef wel met een knagend gevoel achter: hoe makkelijk blijkt het om dankzij een DI-container de verantwoordelijkheden van classes te verwateren - en wat moeten we daarmee?
Zelfs de testpiramide is niet meer heilig!
Ik ben altijd in de veronderstelling geweest dat mijn geautomatiseerde tests een piramidevormige verhouding tot elkaar zouden moeten hebben: aan de basis enorm veel unittests, in het midden een goede hoeveelheid integratietests, en aan de top een bescheiden aantal end to end (E2E) tests. Totdat ik Learning Domain-Driven Design van Vlad Khononov las. (Een aanrader, overigens!)
Testen via de voordeur
Het ideaal van Test-Driven Development is dit: al coderend breid je je testsuite uit, zonder ooit één test te hoeven herschrijven. Het toevoegen van nieuwe functionaliteit gebeurt op zijn best binnen de kaders van een bestaande API. Op zijn slechtst leidt het tot uitbreidingen daarvan - meer niet. Er is, denk ik, een manier om dichter bij dat ideaal te komen. Dat ideaal bereik je door te testen via de voordeur. Dat houdt kort gezegd in dat je je logica idealiter test via dezelfde route als een gebruiker van je code.
Mijn eerste testgedreven stapjes
Na niet één, niet twee, niet drie, niet vier, maar vijf blogs over Test-Driven Development had ik ervoor nodig, voordat ik het aandurfde. Maar nu is het dan eindelijk zover: onlangs heb ik de eerste testgedreven stapjes gezet in mijn professionele carrière. Een mijlpaal!
Nóg een reden om testgedreven te ontwikkelen
Als je mij zou vragen: waarom zou je testgedreven ontwikkelen? dan zou ik zeggen: zodat je tests hebt. Maar in The Art of Agile Development van James Shore vond ik een andere reden. Test-Driven Development dwingt je na te denken hoe het is een stuk code te gebruiken, in plaats van het te implementeren. Het vraagt je om helder te krijgen: hoe kan ik deze functionaliteit zo goed mogelijk ontsluiten, in plaats van: hoe kan ik deze functionalteit zo goed mogelijk bouwen?
Legacy code en Test-Driven Development
TDD gaat over het toevoegen van nieuwe features - per definitie. Immers, wie tests toevoegt voor bestaande code is niet test-driven aan het developen. Maar de meeste ontwikkelaars werken helemaal niet aan greenfield-applicaties. Ze slepen zich dag na dag, week na week door het moeras dat we legacy code noemen. TDD lijkt te zijn weggelegd voor de lucky few onder ons die nieuwe applicaties mogen ontwikkelen. De rest van ons mag ploeteren in bestaande drek. Maar die conclusie gaat toch niet helemaal op.
To polyglot or not to polyglot
Laten we aannemen dat sommige programmeerproblemen zich meer voor objectgeoriënteerde talen lenen, en andere meer voor functionele. Is het dan niet logisch om de taal te kiezen die het best bij het probleem past? Het antwoord op die vraag is: ja en nee. Ja, het is verstandig om the right tool for the job te kiezen - dat is een open deur. Maar zelfs als we aannemen dat de ene taal zich beter leent voor het probleem, is het maar de vraag of het verstandig is dat jij die taal nu inzet om dat probleem op te lossen.
Eén test per keer
Ik hou niet van programmeerboeken die van me vragen dat ik onder het lezen code schrijf. Daar kan zo’n boek niks aan doen, ik houd er nu eenmaal van om een boekje op de bank te lezen, ver weg van mijn laptop. Voor één boek maak ik een uitzondering, en dat is Learning Test-Driven Development van Saleem Siddiqui. Dat boek draait namelijk niet om het eindproduct, de code. Het draait om het proces.
Agile en Test-Driven Development
De meeste ontwikkelaars (waaronder ondergetekende!) schrijven als volgt code. Ze bekijken de specificaties en beginnen vervolgens te klungelen. Dat duurt een tijd, totdat ze iets hebben wat werkt. Of dat zo is, verifiëren ze middels handmatige tests. Pas als de code werkt als bedoeld, schrijft men - als het goed is! - een reeks geautomatiseerde tests. Het is een hardnekkig misverstand dat TDD deze praktijk van software schrijven omdraait: eerst de geautomatiseerde tests (meervoud!) schrijven, en dan pas de productiecode. De werkelijkheid ligt wat genuanceerder.