Was ist "gute" Code Coverage? Ein Leitfaden aus der Praxis

15. Juli 2025

Ich räume mit dem 100-%-Mythos auf: bewährte Coverage-Ziele für TypeScript und PHP, der ROI von Tests und Tooling-Tricks, die ich täglich nutze.

Was ist "gute" Code Coverage? Ein Leitfaden aus der Praxis — 80 % Coverage ≠ 80 % Qualität — und zwar deshalb

Was ist "gute" Code Coverage? Mein Praxisleitfaden, um Bugs zu stoppen, ohne Engineering-Zeit zu verbrennen

Jedes Mal, wenn ich npm run coverage oder phpunit --coverage ausführe, taucht dieselbe Frage auf:

"Okay ... 74 %. Reicht das?"

Die Softwareentwicklungs-Blogosphäre ruft "100 % oder gar nichts!" Währenddessen erinnert mich launchdarkly.com höflich daran, dass 100 % ausgeführt nicht 100 % getestet bedeutet.
Ich habe Wochen damit verbracht, dieser glänzenden Kennzahl hinterherzulaufen, und noch mehr Wochen damit, andere Probleme zu debuggen. Das hier ist der praxiserprobte Mittelweg, bei dem ich gelandet bin.

Warum 100 % Coverage eine Fata Morgana sind

In der Theorie bedeutet 100 % Zeilenausführung: "keine versteckten Bugs." In der Praxis:

Abnehmender Grenznutzen: 90 %→95 % verdoppelt oft deine Testsuite, bringt aber nur eine einstellige Risikoreduktion.
Falsche Sicherheit: Ein Test, der eine Funktion ohne Assertion aufruft, zählt trotzdem als abgedeckt.
Business-Realität: Jeder zusätzliche Test ist Zeit, die nicht in Features fließt, nach denen deine Kunden gefragt haben.

Die Aerospace-Leute können 100 % anpeilen — dort geht es um Leben und Tod. Für den Rest von uns ist ~80 % die 80/20-Linie. Dort landen die meisten Projekte nach ROI-Rechnungen. testdevlab.com nennt aus genau diesem Grund den Bereich 70–90 %.

Die praktische Tabelle, die ich benutze

Coverage	Meine Übersetzung	Handlung
100 %	"Wir sind eine Library, die Raketen fliegt"	Den Aufwand akzeptieren.
90 % +	"Library, von der viel Geld abhängt"	Nur für Module mit hoher Priorität.
80 %	Shippen, beobachten, dann iterieren.
60–70 %	Merge-Gate — PR fehlschlagen lassen, wenn neuer Code dich darunter zieht.
< 50 %	Wochenende mit Tech Debt — zuerst auf kritische Pfade umschwenken.

Ich habe diese Zahlen aus Atlassians internem Leitfaden geklaut: 60 % "acceptable", 75 % "commendable", 90 % "exemplary". Funktioniert in jeder Retro.

Wie ich 80 % erreiche, ohne zu weinen (TypeScript-Playbook)

Jest + Istanbul direkt out of the box

Coverage-Gate in CI
In jest.config.js füge ich hinzu:

coverageThreshold: {
  global: 80,
  '**/src/core/**': 90
}

Ziel sind die heißen Nutzerpfade, nicht der Redux-Boilerplate-Logger.

Wie ich 80 % in Laravel erreiche (PHP-Playbook)

PCOV für Geschwindigkeit in der Entwicklung installieren, Xdebug für Branch-Daten in CI.

PHPUnit + diese Defaults in phpunit.xml:

<filter>
  <whitelist processUncoveredFiles="true">
    <directory suffix=".php">./src</directory>
  </whitelist>
</filter>

Mutation Score > Line Count mit Infection — so finde ich Zeilen, die "abgedeckt, aber nicht wirklich getestet" sind.

4 Regeln, nach denen mein Team lebt

Neuer Code = Tests. Diff Coverage ≥ 90 % vor dem Merge.
Erst refactoren, dann testen. Untestbarer Code ist bereits Debt.
Den Build fehlschlagen lassen, nicht die Menschen. Das Gate jedes Jahr um 5 % senken, statt Teams mit roten Dashboards zu brechen.
Bugs in Produktion messen — wenn Coverage 85 % beträgt, aber Incidents hochgehen, ist Coverage nicht der Schuldige; Assertions sind es.

TL;DR (auch für Executives und Recruiter)

Frag mich nicht nach einer "magischen Zahl". Frag:

Welche Teile des Produkts dürfen nicht kaputtgehen?

Decke diese mit 90 % ab. Gib dem Rest gesunde Smoke Tests. Benutze Code Coverage als Scheinwerfer, nicht als Ziellinie, und vertraue den Bugs, die du fängst, nicht den Zahlen, mit denen du prahlen kannst.

Lass das Coverage-Dashboard grün sein — deine Kunden werden es nie sehen, aber ihre Fehlerleiste bleibt leer.

— Ende des Rants, zurück in den Editor.