Was ist Test-Coverage?

Question

Accepted Answer

**Test-Coverage** misst, wie viel des Codes **durch Tests ausgeführt wird** — typischerweise als Prozentsatz (z. B. 80% Coverage). Es ist eine nützliche Metrik zum Auffinden von ungetesttem Code, aber es ist wichtig, seine Grenzen zu verstehen: hohe Coverage garantiert keine guten Tests.

## Was Coverage misst

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

## Warum Coverage nützlich ist

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

## Die Grenzen (wichtig!)

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

## Warum es wichtig ist

Das Verständnis von Test-Coverage — einschließlich seiner Grenzen — ist wertvoll, weil es eine **häufig verwendete Metrik** ist, die nützlich ist, wenn sie richtig verstanden wird, aber irreführend sein kann, wenn sie missbräuchlich verwendet wird. Daher ist es wichtiges praktisches Wissen.

Coverage misst **wie viel Code durch Tests ausgeführt wird** (als Prozentsatz, über Line-, Branch-, Function- oder Statement-Coverage), und das Verständnis ist nützlich, weil es **ungetesteten Code findet** (Lücken aufdeckt, wo Tests fehlen — eine wertvolle Möglichkeit zu erkennen, was getestet werden muss), ein messbares Qualitätssignal bietet, das Teams verfolgen können, und fehlende Branches und Fehlerfälle hervorhebt.

Viele Teams nutzen Coverage als Qualitätsmetrik mit Zielvorgaben.

Jedoch ist das Verständnis der **Grenzen kritisch wichtig**: **hohe Coverage bedeutet nicht gute Tests** — Coverage zeigt, dass Code *ausgeführt* wurde, nicht dass sein Verhalten korrekt *verifiziert* wurde. Sie können also hohe (sogar 100%) Coverage mit bedeutungslosen Tests haben (Code ausführen ohne ordentliche Assertions verifiziert nichts), und vollständige Coverage kann Bugs trotzdem übersehen (ungetestete Eingabekombinationen, Logikfehler).

Die Gefahr, **eine Coverage-Zahl anzustreben** (Tests mit geringem Wert schreiben, nur um ein Ziel zu erreichen), ist ein echtes Anti-Pattern.

Das Verständnis, dass **Coverage ein nützlicher Leitfaden zum Auffinden von Lücken ist, keine Qualitätsgarantie** — und dass der Fokus auf dem guten Testen wichtiger Verhaltensweisen liegen sollte, nicht auf dem Erreichen eines Prozentsatzes — spiegelt reifes Urteilsvermögen wider, das den häufigen Fehler vermeidet, Coverage als Ziel statt als Werkzeug zu betrachten.

Da Coverage eine weit verbreitete Metrik ist, die wirklich nützlich ist (ungetesteten Code finden), aber häufig missverstanden und missbräuchlich verwendet wird (als Qualitätsgarantie oder als Ziel, das man optimieren kann), und da das Verständnis sowohl ihres Wertes als auch ihrer wichtigen Grenzen die Möglichkeit bietet, sie klug einzusetzen, ist das Verständnis von Test-Coverage wertvoll und praktisch relevantes Wissen — eine nützliche Metrik, die man richtig verstehen sollte, wobei die Wertschätzung ihrer Grenzen (Coverage ≠ Qualität) ebenso wichtig ist wie die Metrik selbst, was solides Test-Urteilsvermögen widerspiegelt.