Auth-Code braucht 90% Mutation Coverage. Deine String-Utils nicht.

Ein einheitlicher Mutation Score für die gesamte Codebase durchzusetzen ist der schnellste Weg, dein Team das Testen hassen zu lassen.

Starte PIT oder Stryker in einem typischen Repo und du siehst immer das gleiche Muster: Authentifizierungsmodule landen bei 40%, String-Utilities bei 95%, und deine ORM-Schicht irgendwo in den 60ern. Der Reflex ist, ein globales Gate bei sagen wir 70% zu setzen und jeden PR zu blocken, der darunter fällt. Zwei Sprints später deaktiviert jemand den Check in der CI und schiebt es auf “flaky mutators.”

Das eigentliche Problem sind nicht die Tools. Es ist die Annahme, dass jeder Code denselben Blast Radius hat, wenn ein Mutant überlebt.

Was Mutation Testing tatsächlich misst

Code Coverage sagt dir, welche Zeilen ausgeführt wurden. Mutation Testing sagt dir, ob deine Tests es merken würden, wenn sich diese Zeilen ändern.

Ein Mutation Framework führt kleine Fehler (Mutanten) in deinen Quellcode ein. Es könnte ein > in ein < umwandeln, einen Methodenaufruf entfernen oder einen Return Value ändern. Wenn deine Test Suite die Änderung bemerkt, wird der Mutant gekillt. Wenn sie trotzdem grün bleibt, überlebt der Mutant. Dein Mutation Score ist der Prozentsatz der getöteten Mutanten.

Ein überlebender Mutant in einem Passwort-Hash-Vergleich ist ein Security Bug, der auf Production wartet. Ein überlebender Mutant in einem capitalizeFirstLetter Helper ist bestenfalls ein etwas seltsames UI Label.

Beide gleich zu behandeln ist der Punkt, an dem Teams falsch abbiegen.

Warum Auth ein Gate von 90%+ verdient

Authentifizierungs- und Autorisierungscode hat zwei Eigenschaften, die ihn ideal für aggressives Mutation Testing machen.

Erstens ist die Logik meist diskret und zustandsbasiert. Ist das Token abgelaufen? Ist die Rolle in der erlaubten Menge? Hat die Signatur geprüft? Jeder Branch hat eine klare Security-Implikation, und jeder einzelne sollte getestet werden.

Zweitens sind die Kosten eines überlebenden Mutanten katastrophal. Ein einzelnes geflipptes Boolean in einem Rollen-Check kann Admin-Endpunkte freigeben. Ein verpasstes not in einer Token-Validierungsroutine kann gefälschte JWTs akzeptieren. Das sind keine theoretischen Szenarien. CVE-Datenbanken sind voll mit Auth-Bypasses, die durch Logikfehler verursacht wurden, die Mutation Testing gefangen hätte.

Bei Sentry erzwingen wir einen Mutation Score von 90% für alles in den Modulen authn/ und authz/. Alles darunter scheitert in der CI. Keine Ausnahmen, kein “wir fixen es im nächsten Sprint.” Das Modul ist klein genug, dass das erreichbar ist, ohne für jede Zeile Production Code 40 Zeilen Test zu schreiben.

So sieht das in der Praxis aus. Das ist eine vereinfachte JWT-Validierungsroutine:

import time
from typing import Optional

def verify_token(token: dict, expected_aud: str, leeway: int = 30) -> bool:
    now = time.time()

    if token.get("aud") != expected_aud:
        return False

    exp = token.get("exp")
    if exp is not None and now > exp + leeway:
        return False

    return True

Ein Mutation Framework könnte das > in >= im Expiry Check umdrehen. Ohne einen Test, der ein Token verwendet, das genau bei now + leeway abläuft, überlebt der Mutant. Das bedeutet, deine Tests verifizieren die Boundary nicht tatsächlich. Bei 90% Mutation Coverage existiert dieser Test.

Utility Code kann mit 60% leben

Deine StringUtils, DateHelpers und MathExtensions sind das andere Ende des Spektrums.

Diese Module sind meist pure, stark wiederverwendet und leicht nachvollziehbar. Ein überlebender Mutant in truncate(str, maxLen), der > in >= ändert, schneidet vielleicht ein Zeichen mehr ab. Das ist ein UI-Quirk, kein Security Incident.

Die Risk-Reward-Rechnung verschiebt sich. Diese Module haben oft Dutzende kleiner Funktionen. 90% Mutation Coverage zu jagen bedeutet, Tests für jede Off-by-One-Variante in padLeft zu schreiben. Die Tests werden länger als der Code, den sie schützen, und der Maintenance Burden überwiegt langsam den Wert.

Wir setzen ein Floor von 60% für Utility-Module. Das fängt die offensichtlichen Lücken ab (fehlende Null Checks, falsche Return Values), ohne das Team zu zwingen, jede String-Slicing-Permutation exhaustive zu testen.

Der Schlüssel ist, ehrlich zu sein, was 60% bedeuten. Es bedeutet “wir haben die Common Cases und die offensichtlichen Failures getestet.” Es bedeutet nicht “dieser Code ist egal.” Wenn eine Utility-Funktion in einem Security-sensitiven Pfad verwendet wird, erbt sie den höheren Threshold von ihrem Consumer.

Die Mitte: Business Logic

Der Großteil deines Codes sitzt zwischen diesen Polen. Payment Processing, Data Validation, Workflow Orchestration. Diese Module beeinflussen Korrektheit und User Trust, aber ein einzelner überlebender Mutant wird einem Angreifer typischerweise nicht deine Datenbank aushändigen.

Wir verwenden ein tiered System:

Modultyp	Mutation Threshold	Begründung
AuthN / AuthZ	90%	Hoher Blast Radius, diskrete Logik
Business Logic	75%	Korrektheitskritisch, moderate Komplexität
Utilities / Helpers	60%	Niedriger Blast Radius, hohe Wiederverwendung, einfache Funktionen
Generated / Boilerplate	Ausgeschlossen	Teste nicht Code, den du nicht geschrieben hast

Das ist keine starre Regel. Ein Payment-Calculation-Modul könnte auf 85% hochgestuft werden. Ein weit verbreiteter JSON-Helper könnte auf 75% aufsteigen, wenn er von Auth-Code konsumiert wird. Die Tiers sind ein Startpunkt, kein Käfig.

Wie man tiered Mutation Gates implementiert

Stryker und PIT unterstützen beide eine Konfiguration pro Modul. So verkabeln wir das in einem Python-Projekt mit mutmut und einer Custom Config:

# mutation_config.py
THRESHOLDS = {
    "src/authn/": 90,
    "src/authz/": 90,
    "src/billing/": 85,
    "src/workflows/": 75,
    "src/utils/": 60,
}

EXCLUDE_PATHS = [
    "src/generated/",
    "src/migrations/",
]

In der CI liest ein kleines Script diese Config und führt den Mutation Tester pro Modul aus:

#!/usr/bin/env bash
# ci/check-mutation.sh
set -e

python -m mutmut run --paths-to-mutate=src/authn/
python -m mutmut results || true
python -m mutmut run --paths-to-mutate=src/utils/
python -m mutmut results || true

python ci/verify_thresholds.py

Das Verification Script prüft den Score jedes Moduls gegen seinen Threshold. Wenn src/authn/ 87% erreicht, failt der Build mit einer klaren Nachricht: authn/ scored 87%, threshold is 90%.

Für Stryker (JavaScript/TypeScript) verwende stryker.conf.js mit Mutator Groups:

// stryker.conf.js
module.exports = {
  thresholds: {
    high: 90,
    low: 75,
    break: null, // wir handhaben das pro Modul
  },
  mutate: [
    "src/auth/**/*.ts",
    "src/billing/**/*.ts",
    "src/utils/**/*.ts",
  ],
  ignorePatterns: ["src/generated/**"],
};

Wir wrappen Stryker in ein Script, das es dreimal mit verschiedenen Path-Globs ausführt und nach jedem Lauf den pro-Directory Threshold erzwingt. Es ist ein bisschen klobig, aber es funktioniert.

Die Falle, 100% zu jagen

Manche Teams sehen Mutation Testing als ein Spiel, das man gewinnen muss. Sie schreiben Tests, die nur existieren, um Mutanten zu killen, nicht um Behavior zu verifizieren.

Das schlimmste Beispiel ist, zu testen, dass eine bestimmte Exception Message einen Substring enthält, nur damit ein Mutant, der den Message Text ändert, gekillt wird. Dieser Test fügt keinen Wert hinzu. Er verifiziert nicht, dass die Exception zur richtigen Zeit geworfen wird, oder dass der richtige Typ raised wird. Er verifiziert nur den String.

Wenn du feststellst, dass du Tests nur schreibst, um einen Prozentsatz zu erhöhen, hast du das Ziel invertiert. Mutation Testing ist ein Diagnose-Tool, kein Leaderboard. Der Score sagt dir, wo du hinschauen sollst. Er sagt dir nicht, wann du fertig bist.

Was wir auf die harte Tour gelernt haben

Wir sind mit einem globalen Gate von 80% gestartet. Innerhalb eines Monats hatten drei Teams es in Feature Branches “temporär” deaktiviert. Zwei dieser temporären Deaktivierungen wurden dauerhaft.

Das Problem war nicht die Zahl. Es war, dass 80% für Auth-Code zu niedrig waren (wir haben einen Rollen-Check Bug übersehen, der bis ins Staging kam) und für ein 4.000 Zeilen Utility Modul zu hoch (das Team hat zwei Wochen damit verbracht, Tests für isValidEmail-Varianten zu schreiben).

Nachdem wir in Tiers aufgeteilt hatten, blieb die Adoption hängen. Auth Teams akzeptierten die 90% Hürde, weil der Scope begrenzt war. Platform Teams akzeptierten 60% für Utilities, weil es ohne Wahnsinn erreichbar war. Der tiered Ansatz verwandelte Mutation Testing von einer Strafe in ein Gespräch über Risiko.

Wo anfangen

Wenn du Mutation Testing in einer bestehenden Codebase einführst, setze in Woche eins keine Gates. Führe das Tool aus, schau dir die Scores an und frag: wo würde ein überlebender Mutant am meisten wehtun?

Fange mit Auth an. Setze dort 90%, bringe es auf Grün und beweise den Wert. Erweitere auf Business Logic, sobald das Team dem Signal vertraut. Halte Utilities an einer niedrigeren Hürde oder schließe sie komplett aus, bis du die Gewohnheit aufgebaut hast.

Und denk daran: ein Score von 60% mit ehrlichen Tests schlägt einen Score von 95% mit Tests, die geschrieben wurden, um den Mutator zu gamen. Das Ziel ist, echte Bugs zu finden, nicht dein Metrics Dashboard zu beeindrucken.

Wenn du das selbst ausprobieren willst, unterstützen mutmut für Python und Stryker für JavaScript beide die oben beschriebenen per-Directory Patterns. Fange klein an. Ein Auth-Modul. Eine Woche. Schau, was überlebt.