Test Coverage

Tools: Jacoco (Java), Istanbul/Jest (JS), Coverage.py (Python). Befehl: jest --coverage. Output: Eine HTML-Datei, wo ungetestete Zeilen rot markiert sind. In der CI/CD Pipeline setzt man oft ein Limit: "Wenn Coverage < 80% fällt, bricht der Build ab." Das zwingt Entwickler, Tests zu schreiben.

1. Line vs Branch Coverage

• Line Coverage: Wurde Zeile 10 ausgeführt?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Tools: Jacoco (Java), Istanbul/Jest (JS), Coverage.py (Python). Befehl: jest --coverage. Output: Eine HTML-Datei, wo ungetestete Zeilen rot markiert sind. In der CI/CD Pipeline setzt man oft ein Limit: "Wenn Coverage < 80% fällt, bricht der Build ab." Das zwingt Entwickler, Tests zu schreiben.
• Branch Coverage: Wurden beide Wege einer if-Abfrage (true UND false) genommen? Beispiel: if (x > 0) print("pos"); Wenn dein Test x=5 setzt, ist Line Coverage 100% (beide Zeilen getroffen). Aber Branch Coverage ist nur 50% (der implizite else-Pfad fehlt). Branch Coverage ist viel wichtiger für Logik-Tests.

2. Mutation Testing (Stryker)

Coverage lügt. Ich kann einen Test schreiben, der alles ausführt, aber nichts prüft (assert(true)). Coverage = 100%. Sinn = 0. Mutation Testing ändert deinen Code ("Mutanten"). Es macht aus a + b ein a - b. Wenn dein Test immer noch "Grün" ist, hast du den Mutanten nicht getötet. Dein Test ist wertlos. Das ist die wahre Coverage ("Wie gut sind meine Assertions?").

3. Exclusions

Manche Dateien will man nicht testen. Config-Files, DTOs (Getter/Setter), Auto-generated Code. Du musst sie in .gitignore (oder .nycrc) ausschließen. Sonst verwässern sie deine Statistik ("Wir haben 90% Coverage!", "Ja, aber nur auf Gettern, die Logik hat 0%").

1. Datenfluss-Abdeckung: Die Logik-Falle

Stell dir vor, du hast eine Funktion mit zwei Parametern if (a && b).

• Condition Coverage: Wurde a einmal als True und einmal als False getestet? Und b auch?

  Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Tools: Jacoco (Java), Istanbul/Jest (JS), Coverage.py (Python). Befehl: jest --coverage. Output: Eine HTML-Datei, wo ungetestete Zeilen rot markiert sind. In der CI/CD Pipeline setzt man oft ein Limit: "Wenn Coverage < 80% fällt, bricht der Build ab." Das zwingt Entwickler, Tests zu schreiben.
• Multiple Condition Coverage (MCC): Wurden alle Kombinationen (T/T, T/F, F/T, F/F) getestet? Oft reicht Branch Coverage nicht aus, um komplexe logische Verknüpfungen abzusichern. Besonders in sicherheitskritischen Systemen (Medizintechnik, Luftfahrt) ist MCC Pflicht, da ein Fehler nur bei einer ganz bestimmten Kombination von Zuständen auftreten könnte.

2. Instrumentierung: Wie wird gemessen?

Woher weiß das Tool (istanbul, jacoco), dass Zeile 42 ausgeführt wurde? Technisch passiert das durch Instrumentation. Das Tool verändert deinen Code vor der Ausführung (entweder den Quellcode oder den Bytecode/Maschinencode). Es fügt überall kleine "Zähler" ein: zähler_zeile_42++;. Nachdem die Tests gelaufen sind, dumpen diese Zähler ihren Status in eine Datei (z. B. lcov.info). Da das Programm durch diese Extra-Operationen langsamer wird, sollte man Coverage-Messungen niemals in Produktion, sondern nur in der CI-Umgebung laufen lassen.

3. Coverage Analysis Berichte (LCOV, Cobertura)

Es gibt kein einheitliches Format für Coverage-Daten.

• LCOV: Das klassische Format von gcov (Linux).
• Cobertura: Ein XML-Format, das oft von Jenkins genutzt wird. Tools wie Codecov oder Coveralls im Web nehmen diese Rohdaten entgegen und erstellen daraus "Sunburst-Diagramme" oder zeigen dir direkt im Pull Request an: "Dieser Commit senkt die Coverage um 1.2%!". Das macht die Metrik für das gesamte Team sichtbar und fördert eine Kultur von hoher Code-Qualität.