Testdesign

Mutationstests sind negativ. TDD-Tests sind positiv.

Beide heißen Tests, aber sie behaupten Gegensätzliches. Ein TDD-Test sagt, was das System tun muss. Ein Mutationslauf kann nur melden, was Ihre Testsuite übersehen hat. Welches Vorzeichen Sie in der Hand halten, entscheidet, was mit dem Ergebnis zu tun ist — und ob Sie einem Test trauen können, den ein Agent geschrieben hat.

Unsere Teststrategie prüfen lassen QA-Automatisierung ansehen

Zwei Arten von Behauptung

Ein testgetriebener Test wird geschrieben, bevor das Verhalten existiert. Er scheitert, dann besteht er, und von da an ist er eine stehende Aussage: diese Eingabe muss zu diesem Ergebnis führen. Die Suite wächst zu einer lesbaren Spezifikation, und weil der Test zuerst entsteht, erzeugt er Druck auf das Design, denn Code, der schwer aufzurufen ist, ist schwer zu testen. Ein Mutationslauf tut etwas strukturell anderes. Er nimmt funktionierenden Code, verändert ihn absichtlich und lässt die Suite erneut laufen. Jedes Ergebnis ist negativ formuliert: diese Änderung blieb unbemerkt. Nichts in dieser Ausgabe sagt, wofür die Software da ist.

Eine grüne TDD-Suite ist eine Menge von Aussagen über Absichten. Ein hoher Mutation Score ist das Fehlen einer bestimmten Art von Gegenbeweis gegen Ihre Suite. Nur eines von beidem ist eine Spezifikation.

Der positive Test

+ Vor dem Code geschrieben, sodass die Anforderung in Worten existiert, bevor sie in Logik existiert
+ Scheitert zuerst, was der einzige billige Beweis dafür ist, dass der Test überhaupt scheitern kann
+ Benennt eine Regel und übersteht deshalb Refactorings: die Interna dürfen sich bewegen, die Behauptung nicht
+ Erzeugt Designdruck, solange das Design noch günstig zu ändern ist
+ Ist für die nächste Person lesbar, auch für den nächsten Agenten

Die negative Prüfung

− Läuft nachträglich, auf Code und Tests, die schon existieren
− Ein getöteter Mutant bringt keine neue Information; nur Überlebende tragen ein Signal
− Ein Überlebender belegt Blindheit, niemals einen Fehler im Produkt
− Sagt nichts über fehlende Anforderungen, nur über Unempfindlichkeit gegenüber den versuchten Änderungen
− Erzeugt einen Bericht und eine Aufgabenliste, kein Artefakt, das jemand behält

Dasselbe Wort, zwei verschiedene Instrumente

	Der positive Test	Die negative Prüfung
Was es behauptet	Das System muss sich so verhalten.	Ihre Suite hat diese Änderung nicht bemerkt.
Was grün beweist	Jedes bisher spezifizierte Verhalten ist implementiert.	Die Suite reagiert auf diese Operatorenmenge. Nichts über Korrektheit.
Was zurückbleibt	Tests und ein Design, das durch ihr Schreiben geformt wurde.	Ein Bericht. Der Wert muss entnommen werden, bevor er verfällt.
Wann es läuft	Fortlaufend, im Minutenrhythmus, während der Code entsteht.	In der CI: inkrementell auf geänderten Dateien oder als nächtlicher Durchlauf.
Kostenmodell	Stetig bezahlt und in die Entwicklung eingerechnet.	Mutanten mal relevante Testlaufzeit. Wächst mit beidem.
Wirkung aufs Design	Testbarkeitsdruck. Ein unhandliches Design schmerzt sofort.	Keine. Es bewertet, was schon existiert.
Wie das Scheitern kommt	Rot, absichtlich, von Ihnen verfasst, Schritt für Schritt.	Ein Überlebender, den niemand geschrieben hat und der nun gedeutet werden muss.

Wie man es tatsächlich betreibt

Mutationstests gelten als unbezahlbar, was fast immer ein Scoping-Problem und kein Werkzeugproblem ist. Diese Reihenfolge hält sie billig genug, um den Kontakt mit einem Lieferplan zu überleben.

Zuerst Coverage herstellen

- Mutationstests auf unabgedecktem Code melden nur das Offensichtliche, und zwar teuer
- Coverage ist das billige Dauergate; Mutation bleibt für Code, der schon abgedeckt ist
- Wählen Sie ein Modul, auf das es ankommt — Zahlungen, Berechtigungen, Preisfindung — statt des ganzen Repositories

Jeden Lauf begrenzen

- Coverage-Analyse pro Test ist der größte Hebel: es laufen nur die Tests, die den Mutanten erreichen
- In Pull Requests nur geänderte Dateien mutieren, im inkrementellen Modus; das ist ein Lauf im Minutenbereich
- Den vollständigen Durchlauf nach Zeitplan halten, außerhalb des kritischen Pfads, wo Laufzeit niemanden kostet

Überlebende in drei Körbe sortieren

- Eine fehlende Anforderung, aus der ein neuer positiver Test wird, benannt nach der Regel
- Ein äquivalenter Mutant, der nichts Beobachtbares ändert, wird einmal dokumentiert und ausgeschlossen
- Code, den keine Anforderung verlangt, wird gelöscht — der billigste mögliche Abschuss

Auf Rückschritt gaten, nicht auf eine Zahl

- Eine break-Schwelle setzen, die das Absinken stoppt, und dort aufhören
- Überlebende als Review-Punkte melden statt als Build-Fehler, damit niemand lernt, ein rotes Build zu ignorieren
- Laufzeit als erstklassige Metrik verfolgen; ein Gate, das wegen Langsamkeit abgeschaltet wird, schützt nichts

Was sich ändert, wenn ein LLM den Code schreibt

Agenten haben dieses Problem nicht geschaffen, aber industrialisiert. Die Vorzeichenfrage hört auf, Philosophie zu sein, sobald Tests und Implementierung denselben Autor haben und dieser Autor ein Modell ist.

Bitten Sie einen Agenten um ein Feature mit Tests, bekommen Sie beides, erzeugt aus einer Lesart der Anforderung, in einem Kontext. War diese Lesart falsch, kodieren die Tests dasselbe Missverständnis und bestehen — und die Coverage sieht hervorragend aus, weil jede Zeile, die das Modell schrieb, von einem Test ausgeführt wird, den das Modell geschrieben hat, um sie auszuführen. Genau das entdeckt ein normales Review am schlechtesten, denn die Tests wirken im Diff vernünftig. Mutationstests sind die billigste automatische Prüfung, die es fängt, aus einem Grund: sie fragen nicht, ob Tests existieren, sondern ob sie reagieren. Ein Test, der die Implementierung spiegelt, merkt nicht, wenn sich die Implementierung ändert.

In den Kreislauf, nicht in einen Bericht

Ein überlebender Mutant ist ungewöhnlich gutes Feedback für einen Agenten: ausführbar, spezifisch und nicht wegzuargumentieren. Ein Absatz Review-Ratschlag wird zur Kenntnis genommen und ignoriert; eine benannte Änderung, die unentdeckt blieb, wird behoben. Genau so arbeitet die hardener-Rolle in Uncle Bobs SwarmForge, die das Mutationswerkzeug Datei für Datei laufen lässt und nicht weitergehen darf, bevor Überlebende erledigt sind.

Das Kriterium in die Schreibanweisung holen

Der beste Satz dieses Projekts steht im coder-Prompt: schreibe Tests, die bei einer plausiblen falschen Implementierung fehlschlagen würden. Das ist ein Mutationskriterium, eingebaut in den Erzeugungsschritt, und viel billiger, als dasselbe eine Stunde später in einem Audit zu entdecken. Nehmen Sie diesen Satz in Ihre eigenen Agenten-Anweisungen auf.

Autor und Hardener trennen

Dasselbe Modell im selben Kontext erklärt Ihnen, warum ein Überlebender in Ordnung ist, denn die Argumentation, die die Lücke erzeugt hat, liegt noch vor ihm. Lassen Sie den Mutationslauf als separaten Schritt mit separatem Kontext laufen, ohne Zugriff auf die ursprüngliche Begründung — nur Diff und Werkzeugausgabe.

Score-Jagd in Maschinengeschwindigkeit erwarten

Mit dem Auftrag, den Mutation Score zu heben, schreibt ein Agent mutantentötende Änderungsdetektoren schneller, als jemand sie prüfen kann. Goodharts Gesetz wirkt bei Agenten schlimmer, weil Volumen gratis ist. Lassen Sie Agenten Überlebende melden und Tests auf Anforderungsebene vorschlagen; die Entscheidung, was die Anforderung ist, bleibt bei einem Menschen oder einer Spezifikationsrolle.

Code bewerten, den ein Agent gerade erzeugt hat

Coverage und Mutation Score zusammen sind ein brauchbares Raster für KI-Arbeit. Lesen Sie sie als Paar — die interessante Information liegt im Widerspruch.

Signal	Was es meist bedeutet	Was zu tun ist
Hohe Coverage, niedriger Mutation Score	Tests wurden geschrieben, um Code auszuführen, nicht um ihn zu prüfen. Die klassische Form modellgenerierter Tests.	Implementierung im Review behalten, Tests verwerfen oder auf Anforderungsebene neu schreiben.
Beides hoch, auf kleinem Diff	Echt gute Arbeit — oder gut getarnte Änderungsdetektoren.	Auf Spies, Snapshots und Aufrufzähler prüfen. Benennen die Behauptungen Regeln, kann es raus.
Überlebende gehäuft auf Fehlerpfaden	Das Modell hat den Happy Path ordentlich gebaut und den Rest erzählt.	Fehlerverhalten explizit spezifizieren, dann Tests auf diese Spezifikation anfordern.
Überlebende in Code ohne Anforderung	Spekulative Allgemeingültigkeit — Optionen, Flags und Abwehrzweige, die niemand wollte.	Code löschen. Das ist ungetestete Komplexität ohne Eigentümer.
Score gestiegen, Tests fassen jetzt Interna an	Der Agent hat die Metrik optimiert, indem er die Suite an die heutige Implementierung geschweißt hat.	Ablehnen. Das nächste Refactoring bricht diese Tests, ohne dass sich Verhalten ändert.
Liste äquivalenter Mutanten wächst schnell	Der Agent streitet mit dem Werkzeug, statt die Suite zu verbessern.	Das Diff selbst lesen. Ausschlüsse sind eine menschliche Entscheidung, einmal, mit notiertem Grund.

Derselbe Überlebende, zwei Antworten

Hier hört das Vorzeichen auf, Philosophie zu sein. Ein Mutationsbericht liefert eine Stelle; was Sie danach schreiben, entscheidet, ob die Suite stärker oder nur steifer wird.

Der Code und der Mutant, der überlebt

Das Entfernen von .trim() ist eine übliche Methodenaufruf-Mutation. Sie überlebt immer dann, wenn keine Fixture umgebende Leerzeichen enthält, und das gilt für die meisten Fixtures — auch für die, die ein Modell für seinen eigenen Code erfunden hat.

// importer.js
const normalise = (value) => value.trim().toLowerCase();

export function importRows(rows) {
	return rows.map((row) => ({ email: normalise(row.email) }));
}

// Surviving mutant: normalise() with .trim() removed.
// The suite passes either way, so the report flags it.

Den Mutanten töten und die Suite verkoppeln

Dieser Test tötet den Überlebenden. Er friert aber auch die aktuelle Implementierung ein: normalise muss erreichbar bleiben und genau so oft aufgerufen werden. Umbenennen, inlinen oder hinter eine Grenze verschieben, und der Test bricht, obwohl sich das Verhalten nicht geändert hat. Ein Agent, der auf den Score optimiert, produziert standardmäßig genau diese Form.

it('calls normalise once per row', () => {
	const spy = vi.spyOn(internals, 'normalise');
	importRows([{ email: ' Ada@Example.COM ' }]);
	expect(spy).toHaveBeenCalledTimes(1);
});

// Green. Mutant dead. Score up.
// Nothing here states what an imported email address should look like.

Die Frage beantworten, die der Überlebende gestellt hat

Derselbe Mutant, derselbe Abschuss, aber die Behauptung ist eine Regel, die auch ein Produktverantwortlicher lesen könnte. Sie geht durch die öffentliche Funktion, die Interna bleiben also beweglich, und sie erklärt sich in sechs Monaten in der Fehlermeldung selbst.

it('trims and lower-cases every imported email address', () => {
	expect(importRows([{ email: ' Ada@Example.COM ' }]))
		.toEqual([{ email: 'ada@example.com' }]);
});

// Same mutant dead, but the suite gained a specification
// instead of a snapshot of today's call graph.

Das Audit billig genug halten, um es zu behalten

json

Coverage-Analyse pro Test ist der größte Performance-Hebel: es laufen nur die Tests, die den jeweiligen Mutanten überhaupt erreichen. Der inkrementelle Modus hält einen Pull-Request-Lauf im Minutenbereich. Die break-Schwelle ist ein Boden gegen Rückschritte, kein Ziel zum Jagen.

{
	"testRunner": "vitest",
	"coverageAnalysis": "perTest",
	"incremental": true,
	"mutate": ["src/**/*.js", "!src/**/*.test.js"],
	"thresholds": { "high": 80, "low": 60, "break": 60 }
}

Das Gate für einen agentengeschriebenen Branch

Zwei unabhängige Fragen, gestellt von einem Schritt, der den Code nicht geschrieben hat: ist dieser Code so geformt, dass man ihn ändern kann, und reagieren die Tests, die ihn schützen, wenn er sich ändert? Beide Antworten landen am Pull Request, und keine ist vom Autor verhandelbar.

CHANGED=$(git diff --name-only origin/main... -- 'src/**/*.js')

# structural: complexity against coverage on touched methods
crap-report --changed-only --threshold 30 $CHANGED || exit 1

# behavioural: do the new tests notice anything?
stryker run --incremental --mutate "$CHANGED"

# survivors are review items with a named requirement attached,
# never a licence to write a test that pins the call graph.

Wo das Negative giftig wird

Dem Score nachjagen

Sobald der Mutation Score ein Ziel ist, entstehen Tests, die Mutanten töten, statt Anforderungen auszusprechen. Sie kommen durchs Review, weil sie grün sind, und sie sind genau die, die beim nächsten Refactoring brechen, obwohl sich am Verhalten nichts geändert hat.

Äquivalente Mutanten bekämpfen

Manche Mutationen ändern den Code, ohne beobachtbares Verhalten zu ändern. Kein ehrlicher Test kann sie töten. Dokumentieren, ausschließen, weitermachen. Zeit hier kauft eine Zahl, kein Vertrauen.

Die Mutation statt der Regel behaupten

Wenn Sie die Anforderung nicht benennen können, die ein neuer Test schützt, haben Sie einen Änderungsdetektor geschrieben. Er meldet künftig jede Bearbeitung als Fehlschlag und bringt dem Team bei, die Testausgabe nicht mehr zu lesen.

Den Autor seine eigene Arbeit härten lassen

Ein Modell, das den Code geschrieben hat, findet für jeden Überlebenden einen Grund, warum er akzeptabel ist, denn seine eigene Argumentation wirkt auf es selbst weiter plausibel. Hardening muss in einem Schritt passieren, der nur Diff und Werkzeugausgabe sieht.

Jeden Überlebenden in eine positive Aussage verwandeln

Den Überlebenden als Frage lesen

- Welches Verhalten müsste gelten, damit diese Änderung etwas kaputt macht?
- Welche Anforderung würde jetzt scheitern, wenn sie jemand aufgeschrieben hätte?
- Wer weiter unten in der Kette würde merken, wenn diese Mutation ausgeliefert würde?

Die Antwort schreiben, nicht den Abschuss

- Den Test nach der Regel benennen, nie nach dem Mutanten oder der Zeilennummer
- Über die öffentliche Oberfläche prüfen, damit die Interna beweglich bleiben
- Wenn die Regel nur durch Offenlegen von Interna erreichbar ist, ist das ein Designbefund, kein Testbefund

Oder den Code löschen

- Wenn keine Anforderung benennbar ist, hängt tatsächlich nichts von dem Verhalten ab
- Ein Überlebender in unspezifiziertem Code ist oft eine tote Anforderung und kein fehlender Test
- Löschen ist der billigste mögliche Abschuss und macht das nächste Audit schneller

Das eine schreibt die Spezifikation, das andere prüft sie

Mutationstests sind kein besseres TDD und kein Ersatz dafür. Sie erzeugen keine Tests, kein Design und keine Aussage über Absichten. Was sie erzeugen, ist eine Liste von Stellen, an denen Ihre Spezifikation unempfindlicher ist als angenommen, und das ist wirklich wertvoll und wirklich etwas anderes.

Diese Arbeitsteilung zählt heute mehr als damals, als beide Aufgaben demselben Menschen gehörten. Tests sollen weiterhin durch TDD entstehen, als positive Behauptungen über Verhalten — auch wenn ein Agent sie schreibt, weshalb die Anweisung, Tests zu schreiben, die bei einer plausiblen falschen Implementierung fehlschlagen würden, in Ihre Prompts gehört. Mutationsläufe prüfen diese Behauptungen anschließend aus einem separaten Kontext, mit dem sich nicht diskutieren lässt. Und kein Überlebender wandert direkt in einen Test: erst in eine Anforderung übersetzen oder den Code löschen, in dem er sitzt. Ein negativer Befund wird nur dann dauerhafter Wert, wenn jemand ihn in eine positive Aussage darüber verwandelt, wofür die Software da ist.

FAQ

Sind Mutationstests besser als Code Coverage?

Sie beantworten eine stärkere Frage zu einem viel höheren Preis. Coverage zählt, ob eine Zeile ausgeführt wurde; Mutation fragt, ob überhaupt etwas geprüft wurde. Nutzen Sie Coverage als billiges Dauergate und Mutationstests als periodisches Audit für Code, auf den es ankommt — und als stehende Prüfung für alles, was ein Agent geschrieben hat.

Wie helfen Mutationstests bei KI-generiertem Code?

Sie fangen genau den Fehler, den Reviews übersehen: Tests, erzeugt aus demselben Missverständnis wie die Implementierung, die bestehen und hervorragende Coverage liefern, während sie nichts prüfen. Mutationstests interessiert nicht, ob Tests existieren, sondern nur, ob sie auf Codeänderungen reagieren, also fällt eine Suite, die die Implementierung spiegelt, sofort auf.

Sollen Agenten Mutationstests selbst laufen lassen?

Ja, als separater Schritt getrennt von dem, der den Code schrieb, und mit Überlebenden als Fragen statt als Score zum Maximieren. Lassen Sie den Agenten Überlebende melden und Tests auf Anforderungsebene vorschlagen; die Entscheidung, was die Anforderung ist, bleibt bei einem Menschen oder einer Spezifikationsrolle, sonst bekommen Sie Änderungsdetektoren in Maschinengeschwindigkeit.

Welchen Mutation Score sollten wir anstreben?

Werte über etwa 80 Prozent gelten üblicherweise als stark und 60 bis 80 Prozent als brauchbar mit echten Lücken, aber die Zahl bedeutet nur pro Modul etwas. Nützlicher ist die Regel, dass es auf geänderten Dateien keinen Rückschritt geben darf, mit einer break-Schwelle, die das Absinken stoppt.

Welche Werkzeuge nutzen Teams?

PIT ist die etablierte Wahl auf der JVM, Stryker Mutator deckt JavaScript, TypeScript, C# und Scala ab, und in Python sind mutmut und cosmic-ray die üblichen Optionen. Alle können einen Lauf auf geänderte Dateien beschränken, und genau das macht die Praxis auf einem Pull Request erschwinglich.

Wo gehören Mutationstests in die CI?

Inkrementell in Pull Requests, beschränkt auf geänderte Dateien mit Coverage-Analyse pro Test, plus ein vollständiger Durchlauf nach Zeitplan. Melden Sie Überlebende als Review-Punkte statt als Build-Fehler und gaten Sie nur darauf, dass der Score nicht zurückgeht.