Close

Wat is codedekking?

In dit artikel wordt uitgelegd hoe je aan de slag kunt met codedekking, hoe je de juiste tool kunt vinden en hoe je de codedekking kunt berekenen.

Headshot van Sten Pittet
Sten Pittet

Mede-auteur


Codedekking is een statistiek die je kan helpen begrijpen hoeveel van je bron wordt getest. Het is een hele nuttige statistiek waarmee je de kwaliteit van je testsuite kunt beoordelen, en we bekijken hier hoe je ermee aan de slag kunt gaan in je projecten.

Hoe codedekking wordt berekend


Tools voor codedekking gebruiken een of meer criteria om te bepalen hoe je code al dan niet werd toegepast tijdens de uitvoering van je testsuite. De algemene statistieken die je in je dekkingsrapporten zou kunnen zien, zijn onder meer:

  • Functiebereik: hoeveel van de gedefinieerde functies zijn opgeroepen.
  • Dekking van de statement: hoeveel van de statements in het programma zijn uitgevoerd.
  • Dekking van branches: hoeveel branches van de controlestructuren (bijvoorbeeld bij statements) er uitgevoerd zijn.
  • Dekking van de voorwaarde: hoeveel van de booleaanse subexpressies zijn getest op een true- en false-waarde.
  • Regeldekking: hoeveel regels broncode er zijn getest.

Deze statistieken worden meestal weergegeven als het aantal daadwerkelijk geteste items, de items in je code en een dekkingspercentage (geteste items/gevonden items).

Deze statistieken zijn gerelateerd, maar wel verschillend. In het triviale script hieronder laten we een JavaScript-functie controleren of een argument een veelvoud van 10 is. We gebruiken die functie later om te controleren of 100 een veelvoud is van 10. Hiermee kun je het verschil begrijpen tussen de functiedekking en de dekking van de branch.

Oplossing bekijken

Software bouwen en gebruiken met Open DevOps

Gerelateerd materiaal

Geautomatiseerd testen in DevOps

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else    return false; }   console.log(isMultipleOf10(100));


We kunnen de dekkingstool istanbul gebruiken om te zien hoeveel van onze code wordt uitgevoerd wanneer we dit script uitvoeren. Nadat we de dekkingstool hebben gebruikt, krijgen we een dekkingsrapport met onze dekkingsstatistieken. We kunnen zien dat hoewel onze functiedekking 100% is, de dekking voor de branches slechts 50% is. Ook kunnen we zien dat de tool voor codedekking van istanbul geen statistiek voor de dekking van de voorwaarde berekent.

Een dekkingsrapport krijgen in de opdrachtregel

Dit komt doordat de else-statement niet is uitgevoerd wanneer we ons script uitvoeren. Als we 100% dekking willen, kunnen we gewoon nog een regel toevoegen, wat in feite nog een test is, om er zeker van te zijn dat alle onderdelen van de if-statement worden gebruikt.

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else     return false; }   console.log(isMultipleOf10(100)); console.log(isMultipleOf10(34)); // This will make our code execute the "return false;" statement.  


Een tweede uitvoering van onze dekkingstool toont nu aan dat 100% van de bron gedekt wordt dankzij onze twee console.log()-statements onderaan.

Op alle criteria 100% dekking bereiken

In dit voorbeeld registreerden we de resultaten in de terminal, maar hetzelfde principe is van toepassing wanneer je je testsuite uitvoert. Je tool voor codedekking houdt toezicht op de uitvoering van je testsuite en vertelt je hoeveel van de statements, branches, functies en regels zijn uitgevoerd als onderdeel van je tests.

istanbul voor JavaScript kan je een gedetailleerd dekkingsrapport geven voor elk pad

Codedekking: 6 tips om aan de slag te gaan


1. De juiste tool voor je project vinden

Afhankelijk van de taal/talen die je gebruikt, kun je verschillende opties vinden om dekkingsrapporten op te stellen. Hieronder zijn een paar van de populaire tools opgesomd:

Een vergelijking van tools kan je ook helpen bij het nemen van je beslissing. Sommige tools, zoals istanbul, sturen de resultaten rechtstreeks naar je terminal, terwijl andere tools een volledig HTML-rapport genereren waarin je kunt zien welk deel van de code niet wordt gedekt.

2. Naar welk dekkingspercentage moet je streven?

Er is geen wondermiddel wat betreft codedekking, en een hoog dekkingspercentage kan nog steeds problematisch zijn als kritieke onderdelen van de toepassing niet worden getest of als de bestaande tests niet robuust genoeg zijn om vooraf fouten goed vast te leggen. Dat gezegd hebbende, wordt het algemeen aanvaard dat een dekking van 80% een goed doel is om naar te streven. Een hogere dekking proberen te bereiken kan duur uitpakken, terwijl deze niet per se meer voordelen oplevert.

De eerste keer dat je je dekkingstool gebruikt, kan het zijn dat je een vrij laag dekkingspercentage hebt. Als je net begint met testen, is dat normaal en hoef je niet de druk te voelen om meteen een dekking van 80% te bereiken. De reden is dat het overhaast nastreven van een dekkingsdoel je team kan forceren om tests te schrijven die elke regel van de code gebruiken in plaats van tests te schrijven die gebaseerd zijn op de zakelijke vereisten van je toepassing.

In het voorbeeld hierboven bereikten we bijvoorbeeld een dekking van 100% door te testen of 100 en 34 veelvouden van 10 waren. Maar wat als we onze functie zouden oproepen met een letter in plaats van een cijfer? Krijgen we dan een waar/onwaar-resultaat? Of krijgen we een uitzondering? Het is belangrijk dat je team tijd spendeert om vanuit een gebruikersperspectief naar testen te kijken en niet alleen door naar regels code te kijken. De codedekking vertelt je niet of je dingen mist in je bron.

3. Eerst focussen op unittesten

In unittests wordt er nagegaan of de individuele methoden van de klassen en componenten werken die in je toepassing worden gebruikt. Ze zijn over het algemeen goedkoop te implementeren en snel uit te voeren en geven je de algemene zekerheid dat het platform een goede basis heeft. Een eenvoudige manier om snel je codedekking te vergroten, is door te beginnen met het toevoegen van unittests, omdat je er met deze ervoor moet zorgen dat je testsuite alle coderegels bereikt.

4. Dekkingsrapporten gebruiken om kritieke missers te identificeren tijdens tests

Al snel staan er zoveel tests in je code dat je onmogelijk kunt weten welk deel van de toepassing wordt gecontroleerd tijdens de uitvoering van je testsuite. Je weet wat er kapot gaat als je een rode build krijgt, maar je kunt moeilijk achterhalen welke componenten de tests hebben doorstaan.

Hier kunnen de dekkingsrapporten je team bruikbare richtlijnen bieden. Met de meeste tools kun je de dekkingsrapporten nauwkeurig onderzoeken om te zien welke items niet aan de tests zijn onderworpen en die vervolgens gebruiken om kritieke onderdelen van je toepassing te identificeren die nog getest moeten worden.

SimpleCoV voor Ruby kan je laten zien welke methoden niet zijn getest

5. Codedekking onderdeel van je continue integratiestroom maken wanneer jij er klaar voor bent

Wanneer je een workflow voor continue integratie (CI) hebt ingesteld, kan het zijn dat je tests falen als je niet een bepaald hoog dekkingspercentage hebt bereikt. Zoals we al eerder zeiden, zou het natuurlijk onredelijk zijn om de foutdrempel te hoog in te stellen, en een dekking van 90% zorgt er waarschijnlijk voor dat je build vaak faalt. Als je doel een dekking van 80% is, kun je overwegen om de foutdrempel op 70% in te stellen als vangnet voor je CI-cultuur.

Nogmaals, wees voorzichtig dat je niet de verkeerde boodschap overbrengt, want als je je team onder druk zet om een goede dekking te bereiken, kan dat slechte testpraktijken tot gevolg hebben.

6. Goede dekking is niet hetzelfde als goede tests

Om een goede testcultuur te creëren, moet je je team laten begrijpen hoe de toepassing zich moet gedragen wanneer iemand de toepassing correct gebruikt, maar ook wanneer iemand deze probeert kapot te maken. Met tools voor je codedekking kun je inzien waar je je aandacht vervolgens op moet richten, maar ze vertellen je niet of je bestaande tests robuust genoeg zijn voor onverwacht gedrag.

Een goede dekking bereiken is een uitstekend doel, maar het moet gepaard gaan met een robuuste testsuite die ervoor kan zorgen dat individuele klassen niet kapot zijn en dat de integriteit van het systeem geverifieerd kan worden.

Je kunt hier meer informatie vinden over de verschillende soorten softwaretests. Bovendien biedt Open DevOps van Atlassian een open toolchain-platform waarmee je een CD-gebaseerde ontwikkelingspipeline kunt bouwen met je favoriete tools. Je kunt ook leren hoe Atlassian en tools van derden testen kunnen integreren in je workflow met onze DevOps-testtutorials.

Sten Pittet
Sten Pittet

Ik zit nu 10 jaar in de softwarebusiness in verschillende rollen, van ontwikkeling tot productmanagement. Nadat ik de afgelopen 5 jaar in Atlassian heb gewerkt aan ontwikkelaartools, schrijf ik nu over het bouwen van software. Buiten het werk om ontwikkel ik mijn vader-vaardigheden met een geweldige peuter.


Deel dit artikel

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Toelichting DevOps

DevOps-community

Afbeelding van kaart

Gratis aan de slag

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up