Hva er testdekning?

Question

Hva er testdekning?

Accepted Answer

**Testdekning** måler hvor mye av koden som blir **kjørt av tester** — typisk som en prosentandel (f.eks. 80% dekning). Det er en nyttig metrikk for å finne utestet kode, men det er viktig å forstå begrensningene: høy dekning garanterer ikke gode tester.

## Hva dekning 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 dekning 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
```

## Begrensningene (viktig!)

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

Å forstå testdekning — inkludert begrensningene — er verdifullt fordi det er en **vanlig brukt metrikk** som er nyttig når den forstås riktig, men misvisende når den brukes feil, så det er viktig praktisk kunnskap.

Dekning måler **hvor mye kode som blir kjørt av tester** (som en prosentandel, via linje-, branch-, funksjon- eller statement-dekning), og å forstå det er nyttig fordi det **finner utestet kode** (som avslører hull der tester mangler — en verdifull måte å identifisere hva som trenger testing på), gir et målbart kvalitetssignal som team kan spore, og fremhever mistet branches og feiltilfeller.

Mange team bruker dekning som en kvalitetsmetrikk med målsettinger.

Men å forstå **begrensningene er kritisk viktig**: **høy dekning er ikke det samme som gode tester** — dekning viser at kode ble *kjørt*, ikke at atferden dens ble riktig *verifisert*, så du kan ha høy (til og med 100%) dekning med meningsløse tester (kjøring av kode uten ordentlige assertions verifiserer ingenting), og full dekning kan fortsatt gå glipp av feil (utestede inndata-kombinasjoner, logikkfeil).

Faren for **å jage et dekningstall** (å skrive lav-verdi tester bare for å nå et mål) er et reelt anti-mønster.

Å forstå at **dekning er en nyttig guide for å finne hull, ikke en garanti for kvalitet** — og at fokus bør være på å teste viktig atferd godt i stedet for å nå en prosentandel — reflekterer moden dømmekraft som unngår den vanlige feilen med å behandle dekning som målet i stedet for et verktøy.

Fordi dekning er en mye brukt metrikk som er genuint nyttig (finner utestet kode) men vanlig misforstått og misbrukt (behandlet som en kvalitetsgaranti eller et mål å manipulere), og fordi å forstå både dens verdi og viktige begrensninger gjør det mulig å bruke det med omhu, er å forstå testdekning verdifull, praktisk relevant kunnskap — en nyttig metrikk å forstå korrekt, der å verdsette dens begrensninger (dekning ≠ kvalitet) er like viktig som metrikken selv, og reflekterer sunn testkompetanse.