Hvad er test-dækning?

Question

Accepted Answer

**Test-dækning** måler hvor meget af koden der **bliver kørt af tests** — typisk som en procentdel (f.eks. 80% dækning). Det er en nyttig metrik til at finde utestet kode, men det er vigtigt at forstå dens begrænsninger: høj dækning garanterer ikke gode tests.

## Hvad dækning måler

```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.
```

## Hvorfor dækning er nyttig

```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
```

## Begrænsningerne (vigtig!)

```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.
```

## Hvorfor det betyder noget

At forstå test-dækning — herunder dens begrænsninger — er værdifuld fordi det er en **almindeligt brugt metrik** der er nyttig når den forstås korrekt, men vildledende når den misbruges, så det er vigtig praktisk viden.

Dækning måler **hvor meget kode der bliver kørt af tests** (som en procentdel, via linje-, gren-, funktion- eller statement-dækning), og det er nyttigt at forstå fordi det **finder utestet kode** (afslører huller hvor tests mangler — en værdifuld måde at identificere hvad der skal testes), giver et målbart kvalitetssignal som teams kan følge, og fremhæver manglende grene og fejlcases.

Mange teams bruger dækning som en kvalitetsmetrik med målsætninger.

Men det er kritisk vigtigt at forstå **begrænsningerne**: **høj dækning betyder ikke gode tests** — dækning viser at kode blev *kørt*, ikke at dens opførsel blev korrekt *verificeret*, så du kan have høj (selv 100%) dækning med meningsløse tests (at køre kode uden ordentlige assertions verificerer intet), og fuld dækning kan stadig gå glip af fejl (utestede input-kombinationer, logikfejl).

Faren ved **at jagte et dækningstal** (at skrive tests med lav værdi bare for at nå målsætningen) er et rigtigt anti-pattern.

At forstå at **dækning er en nyttig guide til at finde huller, ikke en kvalitetsgaranti** — og at fokus bør være på at teste vigtig opførsel godt frem for at nå en procentdel — afspejler modenhed i dømmekraft der undgår den almindelige fejl at behandle dækning som målet i stedet for et værktøj.

Fordi dækning er en bredt brugt metrik der faktisk er nyttig (at finde utestet kode) men ofte misforstås og misbruges (behandlet som en kvalitetsgaranti eller et mål at manipulere), og fordi at forstå både dens værdi og dens vigtige begrænsninger gør det muligt at bruge den klogt, er at forstå test-dækning værdifuld, praktisk relevant viden — en nyttig metrik at forstå korrekt, hvor at værdsætte dens begrænsninger (dækning ≠ kvalitet) er lige så vigtig som metrikken selv, hvilket afspejler sund testingsdømmekraft.