Test-driven maintenance

 
13 oktober 2009

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 :).


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development, Deployment

Tags: , ,


Reacties (3)

  • @André zeker waar. Er zijn nog best wel wat ontwikkelaars te vinden die de unit tests niet onderhouden en laten verwaarlozen. Vaak omdat de deadlines te strak staan en dit een eenvoudige oplossing lijkt om minder code te hoeven schrijven en dus sneller klaar te zijn.

    Maar ja, de kans dat dat goed gaat is wel echt heel klein te noemen. En als het allemaal toch een beetje anders moet na oplevering, dan begint de (technische) schuld op te lopen en op te lopen. En dan laat je de latere ontwikkelaar die een jaar na dato nog een keer een wijziging uit moet voeren zonder unit tests en in een buggy code base nog buiten beschouwing. Het horrorscenario, zeg maar.

    Op het moment dat noodzakelijke investeringen als kosten gezien worden, dan wordt er al niet meer naar de toekomst gekeken en blijft wanhopig doorploeteren de enige optie. Gebeurd niet alleen in software ontwikkeling, volgens mij. :-)

    Geplaatst op 29 oktober 2009 om 9:45 Permalink

  • Je hebt inderdaad gelijk, Rick, dit is gewoon “klassieke” unit testing. Sinds ik deze post heb geschreven heb ik exact dezelfde werkwijze ook al op meer plaatsen teruggezien :).

    In zoverre niets nieuws maar met de recente hype van TDD vergeten we soms dat we unit tests ook in heel andere fasen van een stuk software kunnen gebruiken en dat unit testing achteraf ook wel degelijk meerwaarde heeft.

    Geplaatst op 29 oktober 2009 om 8:43 Permalink

  • Ik denk dat wat je hier beschrijft inderdaad nogal eens vergeten wordt, maar eigenlijk gewoon een standaard onderdeel van TDD is en door de oorspronkelijke bedenkers ook zo gezien wordt.

    Even ingaand op het bug hunting waar je het over hebt: waar je dat op de Veluwe niet kunt toepassen, beveel ik voor bug hunting altijd de drijfjacht aan: sluit zo (met extra tests en runtime informatie) het net om de bug om hem vervolgens simpelweg met een kleine code wijzigingen uit jouw lijden te verlossen. :-)

    Geplaatst op 25 oktober 2009 om 19:47 Permalink