Wat is test coverage?

Question

Accepted Answer

**Test coverage** meet hoeveel van de code **wordt uitgevoerd door tests** — meestal uitgedrukt als een percentage (bijv. 80% coverage). Het is een nuttige meting voor het vinden van code zonder tests, maar het is belangrijk de beperkingen ervan te begrijpen: hoge coverage garandeert geen goede tests.

## Wat coverage meet

```text
TEST COVERAGE = the % of code exercised by the test suite:
  LINE coverage → % of code lines executed by tests
  BRANCH coverage → % of branches (if/else paths) taken
  FUNCTION coverage → % of functions called
  STATEMENT coverage → % of statements executed
→ Coverage tools instrument the code and report what tests do/don't exercise.
```

## Waarom coverage nuttig is

```text
✓ FINDS UNTESTED code — low coverage areas reveal what lacks tests (a gap finder)
✓ A measurable quality signal; track it over time; many teams set a target (e.g. ≥80%)
✓ Highlights branches/paths/error cases that tests miss
```

## De beperkingen (belangrijk!)

```text
⚠️ HIGH COVERAGE ≠ GOOD TESTS:
  → coverage shows code was EXECUTED, NOT that behavior was correctly VERIFIED
  → you can execute code with NO meaningful assertions → 100% coverage, tests verify nothing
  → 100% coverage can still miss bugs (untested input combinations, logic errors)
⚠️ Chasing a coverage NUMBER → writing low-value tests just to hit the target
→ Coverage is a USEFUL guide (find gaps), NOT a guarantee of quality. Use it wisely;
  focus on testing important behavior well, not just hitting a percentage.
```

## Waarom het belangrijk is

Inzicht in test coverage — inclusief de beperkingen ervan — is waardevol omdat het een **veelgebruikte meting** is die nuttig is wanneer correct begrepen, maar misleidend kan zijn bij verkeerd gebruik. Dit is dus belangrijke praktische kennis.

Coverage meet **hoeveel code wordt uitgevoerd door tests** (als percentage, via line, branch, function, of statement coverage), en inzicht hierin is nuttig omdat het **code zonder tests vindt** (hiaten onthult waar tests ontbreken — een waardevolle manier om te identificeren wat getest moet worden), een meetbare kwaliteitssignaal biedt dat teams kunnen volgen, en gemiste branches en foutgevallen aantoont.

Muchos teams gebruiken coverage als kwaliteitsmeting met doelen.

Maar inzicht in de **beperkingen is kritisch belangrijk**: **hoge coverage is niet gelijk aan goede tests** — coverage laat zien dat code *werd uitgevoerd*, niet dat het gedrag correct *werd geverifieerd*. Je kunt dus hoge (zelfs 100%) coverage hebben met zinloze tests (code uitvoeren zonder juiste assertions verifieert niets), en volledige coverage kan bugs nog steeds missen (geteste input-combinaties, logische fouten).

Het gevaar van **het nastreven van een coverage-getal** (tests met lage waarde schrijven alleen maar om een doel te bereiken) is een echte anti-pattern.

Inzicht dat **coverage een nuttige gids is voor het vinden van hiaten, geen garantie voor kwaliteit** — en dat de focus moet liggen op het goed testen van belangrijk gedrag in plaats van het bereiken van een percentage — weerspiegelt rijpende oordeel die de veel voorkomende fout vermijdt om coverage als doel in plaats van als hulpmiddel te behandelen.

Omdat coverage een wijd verspreide meting is die echt nuttig is (het vinden van code zonder tests) maar vaak wordt misbegrepen en misbruikt (behandeld als kwaliteitsgarantie of als doel om mee te spelen), en omdat inzicht in zowel de waarde als de belangrijke beperkingen ervan maakt dat je het verstandig kunt gebruiken, is inzicht in test coverage waardevolle, praktisch relevante kennis — een nuttige meting om correct te begrijpen, waarbij het waarderen van de beperkingen ervan (coverage ≠ kwaliteit) net zo belangrijk is als de meting zelf, wat gezond testingoordeel weerspiegelt.