Test coverage: wanneer en waarom je test coverage moet hebben

Wat is test coverage of testdekking?

Met test coverage, of “code coverage” doelen we op test dekking. Dat is de mate waarin automatische testen zoals unit testen, functionele testen, integratietesten, en eventueel regressietesten, de code van een applicatie raken door de code te testen met scripts. Dit zijn scripts die de juiste werking en het gedrag van de code bewaken. Als het over test coverage gaat is er altijd in meer of mindere mate discussie. Hoeveel test coverage is genoeg? Waar houdt het op? In mijn optiek zijn dat de verkeerde vragen.

De vraag die volgens mij moet stellen is: Wat is het doel van de test coverage?

Mijn antwoord: Om de voorkomen dat je (of het team) dezelfde fout twee keer maakt.

Praktisch gezien is test coverage nooit 100%. Er is geen (voor normale mensen redelijk haalbare) manier waarop je alle code, gebruikershandelingen, systeemintegraties en scenario’s kunt dekken met testen - zelfs niet als je je enkel focust op de “happy flow”. En zelfs al zou het menselijkerwijs haalbaar zijn om testen voor alle scenario’s te schrijven, dan is het om economische redenen niet levensvatbaar.

Testen zouden daarom moeten beginnen met het bieden van dekking voor de sleutelfuncties en componenten die het meest kritisch, foutgevoelig, of het moeilijkst te testen zijn. En testen zouden vanaf dat punt moeten evolueren, net als het project. Automatische testen zouden praktisch moeten zijn, en ondersteunend - en geen op zichzelf staande missie.

Test coverage als waarborg voor onderhoudbaarheid en overdraagbaarheid

De reden waarom test coverage standaard moet worden meegenomen in de ontwikkelaanpak is niet alleen om ervoor te zorgen dat kwaliteit bij doorontwikkeling wordt gewaarborgd. Even belangrijk is de onderhoudbaarheid van de applicatie, en de overdraagbaarheid van het project tussen developers, bureau’s en teams. Als bijvoorbeeld het project van het ontwikkelteam naar een serviceteam en in onderhoud gaat, of als nieuwe mensen moeten gaan werken aan de code, hoeven ze met test coverage niet eerst ieder detail en iedere module door en door te kennen - de tests zorgen dat hun blinde vlekken gedekt zijn.

Tests vormen ook een vorm van documentatie. In het bijzonder zijn functionele tests erg leesbaar voor mensen die niet bedreven zijn in het lezen van- of werken met code. Als je bijvoorbeeld test scripts leest die zijn geschreven in de Gherkin taal, krijg je eigenlijk direct een goed beeld van wat het project is en doet.

En nogmaals: de testen kunnen het beste evolueren, zodat ze steeds meer borging en zekerheid van kwaliteit toevoegen, zo lang als het project ontwikkelt. Voor ieder nieuw inzicht, probleem of component dienen de developers zich af te vragen of automatische testen fouten in de toekomst kunnen helpen voorkomen, en ze dienen een afweging te maken of de toegevoegde waarde van zo’n test dan groter dan- of gelijk is aan de kosten (tijd) voor het implementeren van de testen.