Statusupdate van een ontwikkelaar: Testgedreven deadlock

An article, posted almost 7 years ago filed in bdd, tdd, test, driven, development, deadlock, writer's block, block, status, failsafe, technisch ontwerp, architectuur & schetsen.

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.

ps. omdat Google diens vertaaldienst zou hebben verbeterd dacht ik: eens proberen met m’n laatste blogpost. Ik heb écht weinig veranderingen hoeven te maken: onder de indruk / impressed

Translations: en

Op de hoogte blijven?

Maandelijks maak ik een selectie artikelen en zorg ik voor wat extra context bij de meer technische stukken. Schrijf je hieronder in:

Mailfrequentie = 1x per maand. Je privacy wordt serieus genomen: de mailinglijst bestaat alleen op onze servers.