Geen zorgen, ik waardeer het testen. Maar testgedreven ontwikkeling? Het hangt er van af.

De laatste paar weken heb ik gewerkt aan het bouwen van een crawler. Het laat een reeks geplande taken parallel lopen, die op zichzelf weer nieuwe taken kunnen starten die gedraaid worden in hun eigen wachtrij. Het einddoel is gestructureerde extracten van externe bronnen (lees: webpagina’s) verkrijgen. Maar ik hik al te lang aan tegen verder dan het begin te komen. De basis architectuur komt maar moeizaam tot stand. Het gaat te langzaam. :(

Kleine overwinningen

Zoals voor veel ontwikkelaars zal gelden, is dit niet mijn eerste parser / crawler. Maar dit keer wilde ik een GoedeParser™ maken. Gemakkelijker uitbreidbaar, flexibeler en vooral robuuster, fouttolerant vanaf het begin. Maar ik kom dus maar niet dichter bij het eindresultaat en dat is frustrerend.

De TDD-school leert ons de kleine overwinningen vieren, en oh ja, ik heb al mijn overwinningen gehad. Maar het einde is nergens in zicht. Ik test de beweging van een stap voorwaarts: hebben we één stap vooruit gezet? Ja! Maar zijn we dichter bij het doel gekomen? Het is te moeilijk om in dit donker te zien …

BDD dan?

Je zou kunnen zeggen dat TDD goed is voor testen van het unit tests, en dat wellicht Gedragsgedreven Ontwikkeling (Behaviour Driven Development of BDD) in plaats daarvan beter is. Maar mijn ultieme gedragstest ‘zou’ zijn: Wanneer het dit doet, geeft het een JSON-weergave van de structurele gegevens op site X weer. En dat zou me vervolgens dwingen om dat op de eenvoudigste manier te implementeren … Iets dat ik al te vaak heb gedaan…

Verken!

Ik heb gekozen voor een architectuur die ik wilde verkennen.

Ik zie nu in dat ik aan het verkennen ben. Ik zal de testgedreven benadering voorlopig moeten laten varen. Te zijner tijd zal ik het stof dat neerdaalt wel weer verankeren in tests. Zal het vanaf het begin foultoos zijn? Het is waarschijnlijk een prijs die ik zal moeten betalen, maar op zich zal daar test gedreven ontwikkeling me snel helpen om de fouten die ontdekt worden snel in te dammen: analyseer de stack-trace, schrijf de test die de fout repliceert, en fix het.

Gerelateerd

This article was published earlier on my very own blog:: Statusupdate van een ontwikkelaar: Testgedreven deadlock //

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.