Code coverage, zin of onzin?

Heel wat developers en ontwikkelteams zijn maar wat fier op hun code. Het aantal ingeslopen bugs is quasi nihil en de code coverage behaalt o goed als de 100%. Kan hieruit geconcludeerd worden dat de code, kwalitatief gezien, goed is? Na het lezen van dit stukje zal je beter inzicht hebben in de zin of onzin is van code coverage en welke besluiten je al dan niet kan trekken.

Wat is code coverage?

In de computerwetenschappen is test of code coverage een maatstaf die wordt gebruikt om de mate te beschrijven waarin de broncode van een programma wordt uitgevoerd wanneer een bepaalde testsuite wordt uitgevoerd. Een programma met een hoge codedekking, gemeten als een percentage, heeft meer van zijn broncode laten uitvoeren tijdens het testen, wat suggereert dat het een lagere kans heeft om niet-gedetecteerde softwarefouten te bevatten in vergelijking met een programma met lage codedekking. Veel verschillende statistieken kunnen worden gebruikt om de codedekking te berekenen; enkele van de meest elementaire zijn het percentage van de programma-subroutines en het percentage programma-instructies dat tijdens de uitvoering van de testsuite wordt aangeroepen.

Anders gezegd betekent code coverage hoe goed jouw testset jouw code test. Hierbij wordt veelal in een percentage aangegeven hoeveel regels van code wordt uitgevoerd bij alle tests. Bij een dekking van 85% betekent het dus dat 15% van de code niet door tests worden uitgevoerd. De dekking meet 4 aspecten van de code:

  • Statements, worden alle if paden uitgevoerd?
  • Branches, zijn alle if-else paden uitgevoerd?
  • Functions, worden alle functies / methods aangeroepen?
  • Lines, worden alle regels code uitgevoerd?

Wat is code coverage niet?

De meest voorkomende vergissing bij het gebruik van codedekking is dat het als een doel op zich wordt gebruikt. Code coverage is echter geen doel maar een tool die je ondersteund bij het inzicht verwerven over hoeveel code wordt getest. Een hoge dekking zegt dus in principe ook niets over de kwaliteit van de geschreven code. Bij een programma met een dekking van 100% kunnen nog steeds bugs insluipen of ontstaan.

Code coverage zegt nauwelijks iets over de kwaliteit van de code. Een programma is niet meteen slecht als er een lage dekking is, of juist heel goed als er een hoge dekking is.

Tevens zegt code coverage niets over de kwaliteit van het testen. De dekking geeft alleen aan hoeveel er getest is en geeft niet aan of de tests daadwerkelijk goed controleren of de code doet wat het moet doen.

Hoe omgaan met code coverage?

Nu werd verduidelijkt dat de coverage praktisch geen enkele invloed heeft op de kwaliteit van de geschreven code, is de vraag of we überhaupt dan wel code coverage dienen aan te wenden een logisch vraag. Het antwoord is ja, codedekking helpt development team zeer zeker. Zo kan er bijvoorbeeld per programma worden bepaald dat er een minimale inspanning gestoken dient gestoken te worden in het testen van code. Door de dekking bij iedere toevoeging te meten kan dat worden nagegaan. Je kan dus als ontwikkelingsteam afspreken om 75% van de geschreven regels door een test te laten gaan.

Daarnaast brengt de code coverage gamification mee in het ontwikkelproces. Gamification is het toevoegen van spelelementen aan alledaagse processen. Doordat er een percentage / rapportcijfer wordt gegeven aan elke testtoevoeging zijn developers meer geneigd om tests te schrijven.

Zaak is dat we onthouden dat het inbrengen van code coverage niets zegt over het niveau van de geschreven code  maar dat codedekking enkel aangeeft hoeveel code er wordt uitgevoerd bij tests.

ArneM september 2018