Mutation Testing durchführen, ohne in Survivors zu ertrinken

Ziel

Mutation Testing als routinemässige Prüfung dafür verwenden, dass Tests Fehler erkennen, ohne dass es zu einem CI-Engpass oder einem Bericht voller Survivors wird, auf die niemand reagiert. Ob der Score entkommene Mängel vorhersagt, ist ein eigener Hypothesen-Eintrag; hier geht es um das Vorgehen.

Voraussetzungen

Eine deterministische, reihenfolgeunabhängige Unit-Test-Sammlung; ein Mutation-Testing-Werkzeug für die Sprache (PIT für die JVM, StrykerJS für JavaScript und TypeScript, mutmut für Python, cargo-mutants für Rust); bereits gemessene Zeilenabdeckung, da nicht abgedeckter Code nur "no coverage"-Mutanten erzeugt.

Schritte

1. Das Werkzeug auf ein Modul mit Logik anwenden, nicht auf die gesamte Codebasis, und den Bericht lesen. PITs Dokumentation listet die Ausgänge je Mutant auf: killed, survived, no coverage, timed out, dazu nicht lebensfähige Zustände und Fehlerzustände. Strykers Metrikseite definiert den Mutation Score als Erkannte geteilt durch Gültige Mutanten, wobei Erkannte Kills und Timeouts zählt.
2. Jeden Survivor im Code öffnen. Es ist eines von drei Dingen: eine fehlende Assertion (der Test hat die Zeile ausgeführt, aber nichts geprüft, was von ihr abhängt), ein fehlender Fall (eine Grenze, die kein Test erreicht), oder ein äquivalenter Mutant, der das beobachtbare Verhalten nicht ändern kann, was PITs Dokumentation mit >= 1 gegenüber > 1 veranschaulicht, wenn der Wert stets 2 ist.
3. Die ersten beiden Arten durch stärkere Tests beheben. Bei Äquivalenten den Mutator ausschliessen oder die Zeile annotieren, soweit das Werkzeug es erlaubt, statt künstliche Tests zu schreiben.
4. Die Laufzeit begrenzen: den Lauf auf geänderte Dateien begrenzen oder den inkrementellen Modus nutzen (StrykerJS --incremental verwendet Ergebnisse für Mutanten wieder, deren abdeckende Tests sich nicht geändert haben); ein Timeout je Mutant setzen; Mutatoren abschalten, die für die Codebasis nur Rauschen erzeugen (PIT überspringt standardmässig Zeilen mit Aufrufen gängiger Logging-Frameworks).
5. Den begrenzten Lauf in der CI auf den Diff anwenden und einen vollständigen Lauf nach Zeitplan mit veröffentlichtem Bericht durchführen, nicht als Gate.
6. Den Score je Modul verfolgen und als Ratsche verwenden ("nicht niedriger als beim letzten Lauf") statt als festes globales Ziel.

Erwartetes Ergebnis

Jede Änderung liefert vor dem Review eine kurze Liste konkreter fehlender Assertions, und der Score der wichtigen Module steigt langsam, statt Gegenstand von Diskussionen zu sein.

Grenzen und Prüfbasis

Die Laufzeit vervielfacht sich mit der Zahl der Mutanten, und flackernde oder reihenfolgeabhängige Tests machen Ergebnisse bedeutungslos. Scores sind zwischen Werkzeugen oder Mutator-Sets nicht vergleichbar. Ein hoher Score bei trivialem Code sagt wenig aus; der Aufwand gehört in Module mit Verzweigungslogik. Es wird keine Messung behauptet.