Vad är testtäckning?

Question

Accepted Answer

**Testtäckning** mäter hur mycket av koden som **exekveras av tester** — typiskt som en procentsats (t.ex. 80% täckning). Det är ett användbart mått för att hitta otestade delar av koden, men det är viktigt att förstå dess begränsningar: hög täckning garanterar inte bra tester.

## Vad täckning mäter

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

## Varför täckning är användbart

```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änsningarna (viktigt!)

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

## Varför det är viktigt

Att förstå testtäckning — inklusive dess begränsningar — är värdefullt eftersom det är ett **vanligt använt mått** som är användbart när det förstås korrekt men vilseledande när det missbrukas, så det är praktisk kunskap som är viktig.

Täckning mäter **hur mycket kod som exekveras av tester** (som en procentsats, via rad-, förgrenings-, funktions- eller satsäckning), och att förstå det är användbart eftersom det **hittar otestade delar av koden** (avslöjar luckor där tester saknas — ett värdefullt sätt att identifiera vad som behöver testas), ger en mätbar kvalitetssignal som team kan följa upp, och highlightar missade förgreningar och felfall.

Många team använder täckning som ett kvalitetsmått med mål.

Men att förstå **begränsningarna är kritiskt viktigt**: **hög täckning motsvarar inte bra tester** — täckning visar att kod *kördes*, inte att dess beteende *verifierades korrekt*, så du kan ha hög (även 100%) täckning med meningslösa tester (att köra kod utan korrekta assertions verifierar ingenting), och full täckning kan fortfarande missa buggar (otestade indatakombinationer, logikfel).

Faran med **jaga ett täckningstal** (skriva lågt värdiga tester bara för att nå ett mål) är ett verkligt anti-mönster.

Att förstå att **täckning är en användbar guide för att hitta luckor, inte en garanti för kvalitet** — och att fokus bör ligga på att testa viktig funktionalitet väl snarare än att nå en procentsats — reflekterar mognadsdom som undviker det vanliga misstaget att behandla täckning som målet snarare än ett verktyg.

Eftersom täckning är ett allmänt använt mått som är genuint användbart (hittar otestade delar) men ofta missförstått och missbrukat (behandlat som kvalitetsgaranti eller ett mål att manipulera), och eftersom att förstå både dess värde och dess viktiga begränsningar möjliggör att använda det klokt, är förståelse för testtäckning värdefull, praktisk relevant kunskap — ett användbart mått att förstå korrekt, där att uppskatta dess begränsningar (täckning ≠ kvalitet) är lika viktigt som måttet själv, vilket reflekterar sunt testningsomdöme.