Test Coverage erhöhen: Wo anfangen, wie messen, was bringt’s.
Test Coverage erhöhen: Wo anfangen, wie messen, wann ist es genug?
100% Coverage ist ein schlechtes Ziel. Gute Coverage für das Richtige ist das eigentliche Ziel.
Warum Coverage-Metriken täuschen können
Ein Projekt kann 85% Code-Coverage haben und trotzdem massive blinde Flecken. Wenn die Tests nur Happy-Path testen und alle kritischen Fehlerpfade ungetestet lassen, gibt Coverage ein falsches Sicherheitsgefühl.
Coverage ist eine Metrik. Keine Qualitätsmessung.
Wo anfangen bei niedrigem Coverage
Nicht: Random Files mit Tests belegen, bis die Zahl steigt. Sondern: Business-kritischen Code zuerst. Payment-Logik, Zugriffskontrollen, Berechnungen, Datentransformationen – das sind die Bereiche, wo Bugs echten Schaden anrichten.
Dann: Häufig geänderte Files. Tests dort amortisieren sich schnell, weil sie bei jeder Änderung anschlagen.
Mutation Testing als Qualitätsprüfung
Code Coverage sagt: "Dieser Code wurde ausgeführt." Mutation Testing sagt: "Dieser Code wurde getestet." Indem es künstliche Fehler (Mutations) in den Code einfügt und prüft, ob Tests diese Mutations erkennen.
Für PHP: Infection. Für JavaScript: Stryker. Der Mutation Score zeigt, wie effektiv die Tests wirklich sind.
Coverage-Ziele pro Bereich
Statt eines globalen Coverage-Ziels: differenzierte Ziele. Business-Logic: > 80%. Infrastructure / Framework-Code: kein Ziel (zu viel Aufwand, zu wenig Nutzen). Integration Tests für kritische Flows: alle wesentlichen Flows abgedeckt.
Checkliste Test Coverage
Coverage-Report als Teil des CI-Outputs
Business-Logic-Bereiche identifiziert und priorisiert
Tests für Fehlerpfade und Edge Cases, nicht nur Happy Path
Mutation Testing für kritische Module durchgeführt
Coverage-Ziele pro Bereich definiert (nicht global)
Test Coverage verbessern?
markom.digital hilft beim strukturierten Aufbau von Test-Suites – von der ersten Priorität bis zum laufenden CI-Check.
