Zin (en onzin) van code coverage
Testen, testen, testen. Ook bij softwareontwikkeling is dat het devies. Voor dat je live gaat uiteraard en daarnaast bij iedere uitbreiding en aanpassing. Omdat de code van veel applicaties veel te groot en complex is om volledig handmatig te testen gebruiken we automatische (unit) tests.
Code coverage, wat is dat?
Code coverage is het percentage van je code dat getest wordt door automatische tests. Code coverage is dus een maatstaf voor de hoeveelheid code die bedekt wordt door deze unit tests. Maar zegt dit ook iets over de kwaliteit?
Geen kwaliteitsnorm
Bij PAQT leveren we een applicatie meestal op met een codedekking van minimaal 80%. Voor 100% gaan is niet efficiënt, die laatste 20% ook nog testen kost gewoon te veel tijd en geld. Maar is de kans op softwarefouten bij een hoog percentage code coverage ook behoorlijk laag?
Om maar meteen met de deur in huis te vallen: het antwoord is nee. Als de geschreven tests zélf namelijk niet goed zijn gemaakt, schiet je er niets mee op.
Wanneer je bijvoorbeeld alleen maar test wat er gebeurt als een gebruiker alles goed doet (ook wel de happy path of happy flow genoemd) heb je weinig aan een hoge coverage. Een kwalitatief hoogwaardige test gaat ook na wat er bij onverwacht gedrag gebeurt.
Wel handig richtsnoer
Is het dan zinloos om een applicatie bij iedere oplevering van nieuwe code een percentage code coverage mee te geven? Dat ook weer niet. Wanneer je veel aandacht besteed aan de kwaliteit van de verschillende tests zelf, kan het ontwikkelteam code coverage als richtlijn gebruiken: hoeveel code willen we minimaal getest hebben.
Het gewenste percentage wordt door een team in hun ‘Definition of Done’ en is (bij kwalitatief hoogwaardige tests) een goede indicatie voor de stabiliteit van een applicatie.