Noodzakelijke overhead: Unit testing

 
14 februari 2009

In een discussie gisteren met collega’s kwam het aloude dilemma van unit testing weer eens om de hoek kijken. In diverse projecten zien we dat na de eerste paar weken om de snelheid erin te brengen het schrijven en beheren van unit tests wordt geschrapt. Zeer kwalijk, want meestal wordt het na een half jaar duidelijk dat een goede set aan unit tests ontzettend waardevol kan zijn.

Even buiten de discussie dat unit tests nuttig zijn wil ik graag de conclusies die we trokken omtrent unit testing delen. Allereerst is daar het gegeven: hoe krijgen we het voor elkaar dat unit tests ontwikkeld en bijgehouden worden? Het eerste antwoord is eigenlijk simpeler dan verwacht: drop je GUI component in je backend omgeving. Unit tests moeten je backend functionaliteit testen en uitvoeren. Ontwikkel daarvoor in de plaats niet een of andere user interface waar je op een knopje drukt om je code te testen. Buiten het feit dat GUI componenten zelf ook geunittest zouden moeten worden dwingt dit in elk geval de ontwikkelaars om unit tests te schrijven op ontwikkelde functionaliteit (enkel en alleen al om het gewoon te kunnen runnen). In Dotnet termen zou je kunnen zeggen: ban de F5 toets.

Een andere interessante conclusie was die van coverage. 98%+ coverage moet nooit het doel zijn. Test dingen die niet-triviaal zijn, simpele getters/setters kan je over het algemeen wel ongemoeid laten. Tevens kan je er vanuit gaan dat de JVM / CLR gewoon werkt en blijft werken dus objectcreatie en dat soort zaken hoeven allemaal niet in je testsuite opgenomen te worden.

Dus kort samengevat twee ‘lessons learned’ of ‘best practices’:
1. Drop je GUI component in je backend ontwikkelproces
2. Streef niet naar een zo hoog mogelijke coverage maar test dingen die tests behoeven grondiger.


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


Categorieën: Project- & procesmanagement, Architectuur, Development

Tags: ,


Reacties (4)

  • Eén plaats waar het volgens mij wel vrij stabiel zou moeten zijn is de schil rondom een businessmodel, vaak als ‘servicelaag’ geimplementeerd. Je kunt daar in feite voor al je use cases een service method definieren (uiteraard aggregeren wat dubbel voorkomt) en je tests schrijven op deze service interface.
    Dan kan je onder deze contracten nog zoveel wijzigen als je wilt, maar dan tenminste deze koppelingsschil blijven testen op correctie.

    (Dit werkt overigens in de praktijk; ik kan gewoon unit-testen tegen een WCF Service met een client assembly en (N) Unit tests).

    Geplaatst op 23 februari 2009 om 21:27 Permalink

  • Stefan Bookholt schreef:

    In een aantal projecten veranderd de code van de backend enorm aan het begin van het traject. Iedere dag worden er wel objecten verwijderd, toegevoegd, samengevoegd etc. In deze situatie is het volgens mij niet handig om al unittests te schrijven. Ik zou dit pas doen als de structuur/architectuur compleet duidelijk is van de backend.

    Geplaatst op 18 februari 2009 om 11:29 Permalink

  • Ivo,

    Zeker een goede tip om een build server in te richten. Procestechnisch is het alleen vaak zo dat dezelfde mensen die de code ontwikkelen de buildserver inrichten (en beheren). Als dat ding te vaak begint te zeuren over unit-testing en de tijdsdruk is hoog dan wordt de notificatie gewoon uitgezet (of genegeerd).

    Voor de goede orde: ik heb hier zelf ook last van. Je wilt dus een mechanisme om jezelf te dwingen om het toch te doen. Procestechnisch is een buildserver mooi, maar in je architectuur kan je dus ook sturen door je GUI component af te scheiden.

    Geplaatst op 15 februari 2009 om 14:38 Permalink

  • Ivo Limmen schreef:

    Om de kwaliteit te waarborgen streef ik in projecten er altijd naar om een build server te gebruiken die goed geconfigureerd is en er melding van maakt als er geen unit tests zijn.
    Het niet bouwen van een GUI is zeker een effectief middel.

    Geplaatst op 15 februari 2009 om 10:08 Permalink