Noodzakelijke overhead: Unit testing

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.