Test-driven maintenance

We kunnen met z’n allen zo lekker praten over het ontwikkelproces van een stukje software. Heerlijk is dat. Jammer alleen dat 90% van de tijd (en dus ook het grootste deel van de kosten) van de totale lifecycle van een stuk software er van ontwikkeling geen sprake meer is, maar van beheer.

Helaas is het zo dat ondanks alle goede voornemens software die eenmaal in een beheersfase terecht is gekomen niet altijd even goed is opgezet. Zo zijn we er allemaal vol van om tijdens softwarebouw een hoge coverage van unit tests te bereiken, goede documentatie en uiteraard nette, bugvrije code. Aan veel van dit soort zaken wordt vaak in het begin van een ontwikkeltraject veel aandacht besteed, maar onder tijdsdruk worden dit soort zaken uitgesteld om vervolgens niet meer bijgewerkt te worden.

Hoe ga je nu bijvoorbeeld om met een stuk software dat beheerd moet worden maar waar nauwelijks tot geen unit-tests in zitten? Een goede aanpak is de volgende: los bugs in eerste instantie *niet* op. Natuurlijk moet het probleem opgelost worden, maar misschien nog wel belangrijker is om er voor te zorgen dat het probleem bij herhaling op later moment sneller te vinden en op te lossen is. Ga dus als volgt te werk:

  • Lokaliseer het probleem;
  • Schrijf één of een aantal unit-tests die dit probleem duidelijk signaleert (en dus faalt), vanuit verschillende perspectieven;
  • Los nu pas de bug op: alle unit tests moeten nu uiteraard wel slagen.

Wat winnen we met deze omweg? Ten eerste: we vinden bij herhaling deze bug veel sneller terug. Ten tweede: we krijgen nu met minimale moeite een groeiende testset van het systeem die toekomstige aanpassingen laagdrempeliger maakt. Ten derde: de code wordt beter doorgrond en de bug wordt grondiger opgelost doordat er vanuit verschillende perspectieven naar gekeken wordt. En last but nog least: bug hunting en oplossen wordt een stuk leuker: je schrijft immers weer lekker ook eigen code :).