Testgenerierung mit KI-Coding-Agents: vier Muster gegen trügerische Coverage

Diese Szene wiederholt sich in vielen Teams, sobald Coding Agents zum Einsatz kommen: Der Agent-Modus von Claude Code, Cursor oder Copilot läuft einen Sprint lang, die Testabdeckung klettert von 62 auf 81 Prozent. Die Suite ist grün, das Dashboard zufrieden, der nächste Sprint geplant. Zwei Wochen später rutscht in der Produktion genau die Art von Fehler durch, gegen die eine Test-Suite eigentlich schützen soll: eine Grenzwertbedingung, die niemand geprüft hat.

Der Agent schreibt Tests. Er schreibt nicht automatisch die Tests, die Ihren Code schützen.

Kurz gefasst: Coding Agents erzeugen viele Tests und heben die Coverage. Aber Coverage ist eine Eingangsgröße, kein Qualitätsnachweis: Der ungeführte Agent schreibt lineare, mock-lastige Tests, die sein Modell des Codes prüfen, nicht dessen Verhalten. Vier Muster drehen das um, indem sie dem Agenten ein anderes Optimierungsziel vorgeben als die Abdeckungszahl.

Wer das Thema im Zusammenhang mit Rollout, Tooling und Messung einordnen will, findet im Gesamtüberblick zu Coding Agents im Team den breiteren Rahmen.

Was Agenten gut können

Zuerst die gute Nachricht: Sie ist belastbar. Eine MSR-2026-Studie zur Testgenerierung durch Coding Agents hat 2.232 testbezogene Commits in zehn ausgewählten TypeScript/Vitest-Projekten mit besonders hoher Agent-Aktivität ausgewertet. 16,4 Prozent davon stammten von KI-Agenten. In den 531 Commits aus drei dieser Projekte, für die sich die Abdeckung automatisiert messen ließ, lagen die Zuwächse auf dem Niveau menschlich geschriebener Tests, teils darüber.

Ein verwandter Industriebeleg zeigt, was möglich wird, wenn LLM-Testgenerierung streng gefiltert und in einen Review-Prozess eingebettet ist. TestGen-LLM im Einsatz bei Meta verbesserte bestehende Test-Suiten an Anwendungen im Produktivbetrieb: 75 Prozent der generierten Tests ließen sich fehlerfrei bauen, 57 Prozent liefen zuverlässig grün, 25 Prozent erhöhten die Abdeckung, und 73 Prozent der den Entwicklern vorgelegten Empfehlungen wurden angenommen. Die Zahlen stammen aus dem Industrieeinsatz und werden von den eigenen Ingenieuren berichtet. Das System schreibt Tests nicht aus dem Nichts, sondern bessert vorhandene aus. Es bleibt trotzdem kein Laborbenchmark, sondern ein Bericht aus produktionsnaher Praxis.

Coverage ist eine Eingangsgröße, kein Qualitätsnachweis. Diese Skepsis ist nicht neu und nicht meine Erfindung. Schon 2014 zeigte eine Untersuchung von rund 31.000 Test-Suiten, dass Abdeckung die Fehlererkennung nur schwach bis mäßig vorhersagt, sobald man die Größe der Suite herausrechnet. Coverage sagt Ihnen, welche Zeilen ausgeführt wurden. Sie sagt Ihnen nichts darüber, was tatsächlich geprüft wurde. Der Sprung von 62 auf 81 Prozent ist ein Ausgangspunkt, kein Beweis.

Wie der Agent testet, wenn niemand ihn führt

Überlassen Sie dem Agenten die Wahl, schreibt er Tests mit einer erkennbaren Handschrift. Drei Eigenschaften fallen in den Daten immer wieder auf.

Linear und assertion-dicht. Dieselbe MSR-Studie misst, dass KI-generierte Tests länger sind und mehr Zusicherungen pro Test enthalten als menschliche, aber eine niedrigere zyklomatische Komplexität haben. Sie überschreiten selten Verzweigungsgrad zwei oder drei. Der Agent bevorzugt geradlinige Tests gegenüber solchen mit eigener Fallunterscheidung. Das wirkt auf den ersten Blick sauber, ist aber ein einziges Muster, über alle Fälle gestülpt.

Zu viele Mocks. Eine Untersuchung zu übermäßigem Mocking hat über 1,2 Millionen Commits aus 2.168 Repositories in TypeScript, JavaScript und Python ausgewertet. Agenten fügen ihren Tests häufiger Mocks hinzu als Nicht-Agenten: 36 Prozent gegenüber 26 Prozent. Sie greifen standardmäßig zum Mock, statt je nach Lage zwischen Dummy, Stub, Spy, Fake und Mock zu wählen. Die praktische Folge wiegt schwerer als die Zahl: Solche Tests prüfen das Modell, das sich der Agent vom Code gemacht hat, nicht den Kontakt des Codes mit der Wirklichkeit. Ein Mock prüft Ihre Annahme über das Verhalten. Ein Fake ist eine funktionierende, aber vereinfachte Implementierung, die echtes Verhalten nachbildet und kontrollierbar bleibt. Auch sie ist Testcode und muss gepflegt werden.

Plausibel, aber semantisch fragil. Neuere Untersuchungen verschieben den Befund weg von einzelnen Modellgenerationen hin zur Qualität der erzeugten Suite. Eine Python-Studie mit GPT-4o, Amazon Q Developer und LLaMA 3.3 findet bei LLM-generierten Tests weiterhin Wartbarkeitsprobleme: Unter 512 erkannten Smells ist mangelnde Kohäsion der Testfälle mit 41,2 Prozent der häufigste, Assertion Roulette folgt mit 24,2 Prozent. Noch wichtiger für Coding Agents ist eine Untersuchung zur Testgenerierung unter Codeänderungen über acht Modelle und 22.374 Programmvarianten: Auf unverändertem Code erreichen die Modelle hohe Abdeckung mit vollständig grünen Suiten. Sobald sich der Code ändert, sinken Pass-Rate und Branch Coverage deutlich, und über 99 Prozent der fehlschlagenden Tests bestehen weiterhin gegen den ursprünglichen Code, obwohl sie die geänderte Stelle ausführen. Die Autoren deuten das so, dass LLM-Testgenerierung stark auf Oberflächenmuster reagiert und sich nicht zuverlässig an veränderte Semantik anpasst. Genau das macht solche Tests später teuer: Sie wirken plausibel, prüfen aber nicht stabil das Verhalten, das geschützt werden muss.

Die Befunde zu Wartbarkeit und semantischer Fragilität stammen aus LLM-Testgenerierung ohne Repository-Agenten, nicht aus Agent-Commits. Die beiden anderen Befunde kommen aus Agent-Commits. Zusammen zeigen sie keine zwingende Eigenschaft jedes Tools, aber eine klare Grundtendenz: Ohne Führung entstehen schnell lineare, mock-lastige und schwer wartbare Tests.

Ohne Vorgaben entsteht eine Suite, die auf sichtbare Metriken zielt: Coverage und grüne Builds, nicht das Finden von Fehlern. Auf die Eigenschaften, die eine Test-Suite in sechs Monaten noch nützlich machen, optimiert dabei niemand.

Vier Muster, die den Agenten besser führen

Jedes der folgenden Muster ändert das Erfolgskriterium des Agenten. Statt Abdeckung bekommt er ein fehlschlagendes Verhalten, eine festgehaltene Beobachtung oder einen Mutanten, den er töten muss.

Test zuerst, Implementierung danach, Commit dazwischen

Lassen Sie den Agenten den Test schreiben, bevor die Implementierung existiert. Bestätigen Sie, dass der Test rot ist. Dann erst entsteht der Code, der ihn grün macht. Anthropics Anleitung für Claude Code weist in dieselbe Richtung: In einem Beispiel-Prompt steht ausdrücklich „avoid mocks“, und Anthropic empfiehlt, zuerst einen fehlschlagenden Test zu schreiben, der den Fehler reproduziert, und ihn dann zu beheben.

Der tragende Schritt steht in keiner Tool-Dokumentation, er ist klassische Disziplin in der Tradition von Kent Beck: committen Sie den fehlschlagenden Test, bevor die Implementierung beginnt. Ohne diesen Commit ändert der Agent unter Umständen still den Test, damit die Implementierung durchläuft, und der Diff ist Ihre einzige Chance, das zu bemerken. Testgetriebene Entwicklung mit einem Agenten passiert nicht von selbst. Ohne Vorgabe landet er leicht bei der bequemeren Reihenfolge: erst Implementierung, Tests hinterher. Sie müssen die Reihenfolge erzwingen.

Charakterisierungstests vor jedem Refactor

Bevor Sie Altcode anfassen, lassen Sie den Agenten Tests schreiben, die festhalten, was der Code gerade tut, nicht was er tun sollte. Der Begriff stammt von Michael Feathers und ist älter als jeder Coding Agent, aber wenn ein Agent beteiligt ist, gewinnt er an Wert. Ich formuliere das für meine Agenten so, festgehalten in The Magic Words That Make AI Code Better: "Add characterization tests around the current behavior before changing it."

Der Agent erzeugt eine Momentaufnahme des Verhaltens vor der Änderung, und alles, worauf sich jemand unbemerkt verlassen hat, wird sichtbar. Diese Tests konservieren auch vorhandene Fehler, und das ist beabsichtigt: Ein Refactor darf das Verhalten nicht ändern, der Bugfix kommt danach als eigener, sichtbarer Schritt. Wie das in einem fünfzehn Jahre alten Monolithen aussieht, beschreibt der Beitrag zur Legacy-Refaktorierung mit Coding Agents.

Ein fehlschlagender Test vor dem Bugfix

Wird ein Fehler gemeldet, schreibt der Agent zuerst einen Test, der auf dem aktuellen Code fehlschlägt. Der Fix wird gegen diesen Test bewertet, nicht gegen ein Gefühl. Coding Agents formulieren Issues als fehlschlagende Tests überraschend gut: Sie reproduzieren echte GitHub-Issues besser als eigens dafür gebaute Systeme, und als Filter für vorgeschlagene Korrekturen eingesetzt, verdoppelten solche Tests in der SWT-Bench-Auswertung die Precision des dort getesteten SWE-Agent-Setups. Behandeln Sie jeden Produktionsfehler so, der durch die Review-Warteschlange aus dem Engpass-Beitrag gerutscht ist: kein Fix ohne vorausgehenden roten Test.

Mutationstests als Maßstab für kritische Pfade

Für Bezahlung, Authentifizierung und regulierte Datenverarbeitung ist Coverage das falsche Abnahmekriterium. Hier hilft Mutation. Mutationsgeleitete Testgenerierung bei Meta erzeugt wenige gezielte Mutanten für eine konkrete Fehlerklasse und dann Tests, die diese Mutanten töten. 73 Prozent der so generierten Tests wurden angenommen, 36 Prozent als datenschutzrelevant eingestuft. Das ist kein Muster für jeden Pull Request, sondern für die Pfade, auf denen "alle Tests grün" nicht genügt. Mutationstests galten lange als zu teuer für den breiten Einsatz. Bei eng umrissenen Fehlerklassen verschiebt sich diese Rechnung gerade.

Die vier Muster haben eine gemeinsame Eigenschaft: Sie geben dem Agenten ein anderes Optimierungsziel als die Coverage.

Was Sie in CLAUDE.md, AGENTS.md oder Cursor Project Rules schreiben sollten

Die Muster oben beschreiben die Haltung. Die folgenden Regeln sind das, was Sie direkt in eine Agent-Konfiguration übernehmen können, um die beschriebenen Tendenzen zu korrigieren:

# Test-Regeln für Coding Agents

1. Mocks sind nicht der Standard für Isolation. Erste Wahl ist ein Fake
   oder ein echter In-Memory-Store. Ein Mock ist zu begründen, nicht
   vorauszusetzen.
2. Keine Assertion-Roulette-Tests. Jede Zusicherung bekommt eine eigene
   Test-Methode oder eine eigene Fehlermeldung.
3. Keine Magic Numbers in Zusicherungen. Jeder numerische Vergleichswert
   bekommt einen Namen oder einen Kommentar, der ihn erklärt.
4. Kritische Pfade (Auth, Bezahlung, DSGVO-relevante Verarbeitung):
   zuerst ein Test, der den Fehler reproduziert oder die Eigenschaft
   prüft, dann die Implementierung.
5. Vor einem Refactor ohne ausreichende Abdeckung: zuerst
   Charakterisierungstests, committen, dann refaktorieren.

Regel eins ist die schärfste, und sie ist keine reine Geschmacksfrage. Die oben zitierte Mocking-Untersuchung empfiehlt selbst, dass Agent-Konfigurationsdateien Vorgaben zur Mocking-Praxis enthalten sollten. Sie halten damit schriftlich fest, was die Forschung ohnehin nahelegt.

Das ist kein vollständiger Test-Leitfaden, sondern ein Satz korrigierender Vorgaben für die heutigen Eigenheiten der Agenten. Für eine andere Sprache, ein anderes Framework oder eine andere Team-Kultur müssen Sie ihn anpassen.

Ein Test ist eine Entwurfsentscheidung

Tests zu schreiben ist Entwurfsarbeit. Die Frage, die zählt, lautet: Was soll dieser Code tun? Ein Coding Agent baut Vorbereitung, Ausführung und Prüfung schneller, als ein Mensch sie tippen könnte. Die fachliche Verantwortung dafür, was der Code tun soll, kann er nicht übernehmen. Genau diese Entscheidung macht einen Test überhaupt erst erhaltenswert.

Ein gutes Test-Audit prüft nicht nur die Coverage, sondern Mock-Dichte, Smell-Verteilung, die kritischen Pfade und das Verhalten bei Mutationen. Genau dort trennt sich eine grüne Suite von einer belastbaren. Für Teams, die schon KI-generierte Tests im Repository haben, lohnt sich ein einmaliges Audit entlang dieser vier Kriterien.

Quellen

• Yoshimoto et al.: Testing with AI Agents: An Empirical Study of Test Generation Frequency, Quality, and Coverage (MSR 2026)
• Hora & Robbes: Are Coding Agents Generating Over-Mocked Tests? (MSR 2026)
• Alves et al.: Quality Assessment of Python Tests Generated by Large Language Models
• Haroon, Khan & Gulzar: Evaluating LLM-Based Test Generation Under Software Evolution
• Alshahwan et al. (Meta): Automated Unit Test Improvement using LLMs at Meta (FSE 2024)
• Foster et al. (Meta): Mutation-Guided LLM-based Test Generation at Meta (FSE 2025, Industry Track)
• Mündler et al.: SWT-Bench: Testing and Validating Real-World Bug-Fixes with Code Agents
• Inozemtseva & Holmes: Coverage Is Not Strongly Correlated With Test Suite Effectiveness (ICSE 2014)
• Anthropic: Best practices for Claude Code
• Kent Beck: Test-Driven Development. By Example (Addison-Wesley, 2002), zur Disziplin des fehlschlagenden Tests vor der Implementierung.
• Michael Feathers: Working Effectively with Legacy Code (Prentice Hall, 2004), zur Herkunft der Charakterisierungstests.