Die Tests, die niemand löscht

Endlich schreibt jemand die Tests

Fast jeder, der mit Agenten arbeitet, kennt diesen Moment. Seit Monaten liegt ein Modul ohne ordentliche Tests herum, alle wissen es, und keiner kommt dazu. Dann bittet man Claude darum, und kurz darauf steht eine ganze Testklasse da. Sie läuft grün und enthält sogar Fälle, die man selbst übersehen hätte. Die Erleichterung ist groß und berechtigt.

Ein paar Monate später sieht dasselbe Repository anders aus. Die Suite hat sich verdreifacht, und den größten Teil davon hat niemand gelesen. Der grüne Balken in der CI meldet jetzt vor allem eines: dass sehr viele Tests durchlaufen.

Jeder Test ist Code, der mitgepflegt werden muss

Tests sind Code. Ein Test, der Verhalten prüft, hängt an jeder Einzelheit, die er abfragt: Methodennamen, Rückgabeformate, Fehlermeldungen, die Reihenfolge der Aufrufe im Mock. Ändert sich die Anwendung, müssen die Tests mit. John Ousterhout nennt das „Change Amplification“: Eine scheinbar einfache Änderung erzwingt Anpassungen an vielen Stellen (Quelle). Jede Prüfung in einem Test ist eine weitere solche Stelle.

Schon vor den Agenten wuchsen die Tests in den meisten untersuchten Projekten schneller als der Code. Seit Agenten mitschreiben, kommt noch mehr dazu: Mitte 2025 fasste bereits mehr als die Hälfte der Pull Requests, die Agenten stellten, auch Testdateien an (Zahlen im Anhang).

Dass Suiten dadurch langsamer werden, beobachten wir in Kundenprojekten. Eine belastbare Studie dazu kennen wir nicht, nur die Angaben eines CI-Anbieters: Bei ihm fallen mehr Läufe an, und das mittlere Team verbraucht dort pro ausgelieferter Änderung mehr CI-Credits. Auch die Erklärung, das liege an der KI, stammt von ihm (Zahlen im Anhang).

An anderer Stelle haben wir beschrieben, wie Agenten Code zur Wegwerfware machen. Tests hebt bisher jeder auf, und mit jedem Agentenlauf kommen neue dazu.

Welches Verhalten kein Test prüft

Partha Protim Paul und Reid Holmes haben eine Frage untersucht, die kein Abdeckungsbericht beantwortet: Welches Verhalten, das eine Methode zeigen soll, prüft überhaupt kein Test? Ihr Werkzeug liest dazu Dokumentation und Quelltext jeder Methode, leitet daraus die einzelnen erwarteten Verhaltensweisen ab und sucht zu jeder den passenden Test. Was danach ohne Test dasteht, nennen die Autoren die Verhaltenslücke.

In den Suiten, die Entwickler selbst geschrieben haben, bleibt mindestens jedes sechste erwartete Verhalten ungeprüft. Für vier der Bibliotheken gibt es auch generierte Suiten, und die schneiden schlechter ab, gleich, ob ein klassischer Generator sie erzeugt hat oder ein Sprachmodell. Am meisten bleibt bei der Suite aus dem Sprachmodell offen.

Die Zeilenabdeckung verrät davon wenig. Bei allen drei Arten von Suiten erreicht der größte Teil der Methoden eine hohe Zeilenabdeckung. Generierte Suiten sehen im Abdeckungsbericht also gut aus und prüfen trotzdem weniger von dem, was der Code tun soll.

Die Studie ist ein Preprint vom Juni 2026. Aufbau, Zahlen für die einzelnen Projekte und Einschränkungen stehen im Anhang, dort auch als Grafik.

Warum Abdeckung und Mutationsbewertung die Lücke übersehen

Zeilenabdeckung zählt jede ausgeführte Zeile mit, auch wenn der Test das Ergebnis danach nie ansieht. Deshalb haben selbst vollständig abgedeckte Methoden oft noch ein Verhalten, das niemand prüft (Zahlen im Anhang).

Die Mutationsbewertung ist strenger. Sie baut kleine Fehler in den Code ein und zählt, wie viele davon die Suite bemerkt. Trotzdem hat fast ein Drittel der Methoden, bei denen die Entwicklersuiten jeden eingebauten Fehler erkennen, noch eine Lücke.

Heikel wird es, sobald diese Kennzahlen zum Aufräumen dienen. Wer eine Suite nach Abdeckung ausdünnt, verliert messbar an Fehlererkennung. Das zeigt sich an künstlich eingebauten Fehlern ebenso wie an echten fehlgeschlagenen Builds: Tests, die ein Reduktionsverfahren für überflüssig erklärt hatte, fanden dort weiterhin Fehler (Studien im Anhang).

Wie Meta generierte Tests aussiebt

Meta hat 2024 beschrieben, wie generierte Tests dort in die Codebasis gelangen. Das Werkzeug TestGen-LLM schickt jeden Kandidaten durch drei Filter: Er muss sich bauen lassen, zuverlässig bestehen und die Zeilenabdeckung erhöhen. Was danach übrig ist, sieht sich ein Mensch an.

Bei drei Vierteln der untersuchten Testklassen kam kein einziger generierter Test durch alle drei Filter (Zahlen im Anhang). Der letzte Filter misst nur Zeilenabdeckung, mit den Schwächen aus dem vorigen Abschnitt. Immerhin gibt es bei Meta eine Hürde, und die fehlt in vielen Teams, die Agenten Tests schreiben lassen.

Der stärkste Einwand: Agenten reparieren Tests in Minuten

Das beste Gegenargument stammt von Simon Willison. Sinngemäß schreibt er, die alten Gründe gegen das Testen seien hinfällig, seit ein Agent kaputte Tests in wenigen Minuten wieder zum Laufen bringt (Zitat im Anhang). Damit wäre Change Amplification kein Problem mehr.

Für das Umschreiben stimmt das. Teuer bleibt die Entscheidung, ob der umgeschriebene Test noch das richtige Verhalten prüft, und die Verhaltenslücke wird nicht kleiner, wenn ein Agent schneller anpasst. Wir behaupten deshalb weniger: Die Kosten der Testpflege wachsen mit der Menge ungelesener Tests, und diese Menge wächst in den Projekten, die wir kennen, derzeit schnell.

Was Teams jetzt konkret ändern können

Generierte Tests müssen eine Hürde nehmen. Ein Kandidat gelangt nur ins Repository, wenn er sich bauen lässt, wiederholt stabil besteht und ein Verhalten prüft, das noch kein anderer Test prüft. Im Review steht deshalb zu jedem generierten Test, welches Verhalten er absichert. Fehlt diese Angabe, fehlt der Grund für den Test.

Gemessen wird am Diff. Die Idee aus der Studie braucht kein fertiges Werkzeug. Für jede geänderte Methode listet ein Agent im Review die dokumentierten Verhaltensweisen auf und ordnet ihnen die Tests zu, die sie prüfen. Die Lücken sieht sich ein Mensch an. Bei einem Diff ist die Liste so kurz, dass das auch wirklich geschieht.

Erst Tests gezielt auswählen, dann CI-Kapazität kaufen. Bevor ein Team mehr Rechenzeit kauft, sollte es vorhersagen lassen, welche Tests eine Änderung überhaupt betrifft. Facebook hat das mit einem trainierten Modell vorgemacht: Es wählt deutlich weniger Tests aus als eine Auswahl nach Build-Abhängigkeiten und meldet trotzdem fast jede fehlerhafte Änderung. Die Maschinenkosten fürs Testen halbierten sich (Einzelheiten im Anhang).

Gelöscht wird regelmäßig. In den untersuchten Java-Projekten löscht kaum ein Commit einen Test, und wenn Tests verschwinden, dann fast immer zusammen mit dem Produktionscode, den sie geprüft haben. Auch Googles Löschwerkzeug entfernt Tests nur zusammen mit totem Code (Belege im Anhang). Ein Team, das bestandene Tests für noch genutzten Code planmäßig löscht, haben wir nicht gefunden. Genau das empfehlen wir, mit dem Verhalten als Maßstab, denn wer nach Abdeckung löscht, verliert echte Fehlerfunde (siehe Anhang). Ein Test, der als einziger ein Verhalten prüft, bleibt. Einer, der zum dritten Mal dasselbe prüft oder ein Verhalten, das es nicht mehr geben soll, kommt weg. Eine feste Stunde im Monat, in der das Team gezielt Tests entfernt, bringt mehr als drei Dashboards.

Unser Versuch: Tests an Geschäftszielen messen

Paul und Holmes leiten Verhalten von unten ab, aus der Dokumentation einzelner Methoden, also auf der Ebene, auf der Code entsteht. Was zählt, entscheidet das Unternehmen weiter oben, bei seinen Zielen. Dort setzt Impact Mapping an: vom Ziel über die Akteure zu den Wirkungen, die bei ihnen eintreten sollen.

Wir probieren derzeit in Projekten aus, ob sich daraus ableiten lässt, was eine Testsuite prüfen muss. Konkret leiten wir aus der Impact Map die Verhaltensweisen ab, an denen ein Ziel hängt, gewichten sie nach ihrer Bedeutung fürs Geschäft und prüfen, welche davon ein Test abdeckt. Ein Test, der sich keiner Wirkung auf der Karte zuordnen lässt, wird zum Kandidaten fürs Löschen.

Wir haben keine veröffentlichte Arbeit gefunden, die eine Impact Map als Maßstab nutzt, um die Güte einer Testsuite zu messen oder über Löschungen zu entscheiden. Am nächsten kommen zwei Arbeiten (Quellen im Anhang): Gojko Adzic und seine Mitautoren nennen die Wirkungen auf der Karte einen guten Ausgangspunkt, um beim explorativen Testen darüber zu sprechen, was Nutzer mit einem System tun können, und ein anderes Verfahren streicht redundante Tests, ohne dass eine Anforderung ungeprüft bleibt. Unser Versuch nimmt Adzics Hinweis auf und trägt ihn vom explorativen Testen in die Pflege der Suite.

Ergebnisse haben wir noch keine. Herausfinden wollen wir zweierlei: ob sich Tests mit vertretbarem Aufwand einzelnen Wirkungen zuordnen lassen, und ob eine Rangfolge nach Geschäftsgewicht zu anderen Entscheidungen führt als die Abdeckung. Aufgeben werden wir die Idee, wenn die Zuordnung mehr Arbeit kostet, als sie beim Priorisieren und Löschen spart, oder wenn am Ende dieselben Tests oben stehen wie ohne Karte. Sobald es etwas zu berichten gibt, schreiben wir darüber einen eigenen Artikel mit Messwerten.

Warum uns das Thema selbst betrifft

Wir bauen mit Agenten in Kundensystemen, also wachsen die Suiten auch bei uns. Unsere Antwort darauf fällt bescheiden aus: Wir messen die Verhaltenslücke dort, wo wir Code ändern, und löschen Tests gezielt. Beide Gewohnheiten gehören auch in jedes 100-Tage-Engagement zur Modernisierung der Entwicklungsorganisation.

Ein grüner Balken ist nur so viel wert wie das Verhalten, das die Tests dahinter wirklich prüfen.

Anhang: Zahlen und Quellen

Hier stehen die Belege zu den Abschnitten oben: Zahlen, wörtliche Zitate, der Aufbau der Studien, ihre Einschränkungen und die Quellenangaben.

Change Amplification

John Ousterhout, A Philosophy of Software Design, 2. Auflage, Kapitel 2. Ousterhout beschreibt Change Amplification für Code im Allgemeinen. Die Übertragung auf Testcode stammt von uns.

Wachstum der Testsuiten

• Tests vor den Agenten: In den meisten von neun ausgereiften C/C++-Projekten kamen mehr Testzeilen hinzu als ausführbare Zeilen (Bailey, Cadar, ICST 2025).
• Tests von Agenten: Der Anteil agentischer Pull Requests, die mindestens eine Testdatei anfassen, stieg von Januar bis Juli 2025 von 31 auf 52 Prozent (Haque, Ingale, Csallner, MSR ‘26). Gezählt sind dabei Pull Requests, keine Zeilen.
• CI-Last: CircleCI zählte im September 2025 59 Prozent mehr tägliche Workflow-Läufe als ein Jahr zuvor, und im März 2026 verbrauchte das mittlere Team dort 13 Prozent mehr CI-Credits pro ausgelieferter Änderung. Das sind Angaben eines Anbieters, und von ihm stammt auch die Deutung, KI sei die Ursache.

Die Studie von Paul und Holmes

Partha Protim Paul, Reid Holmes: „Beyond Coverage and Kill Scores“, arXiv:2606.10417, Preprint vom Juni 2026, noch nicht begutachtet.

Aufbau. Der Forschungsprototyp BFinder liest Dokumentation und Quelltext einer Methode, leitet daraus die einzelnen Verhaltensweisen ab, die sie zeigen soll, und ordnet jeder davon die vorhandenen Tests zu. Was danach ohne Test dasteht, nennen die Autoren die Verhaltenslücke. Untersucht haben sie zehn Java-Bibliotheken aus Defects4J mit 8.922 dokumentierten Methoden. Daraus gewann BFinder 20.729 Verhaltensweisen, von denen sich bei der Nachprüfung 93,1 Prozent als korrekt erwiesen.

Entwicklersuiten. Mindestens 17,5 Prozent der erkannten Verhaltensweisen prüft kein einziger Test. Je nach Projekt sind es 6,6 Prozent (commons-cli) bis 29,3 Prozent (jfreechart).

Warum die Zahl eine Untergrenze ist. Die Autoren haben die gefundenen Lücken bereits mit dem geschätzten Anteil echter Treffer (71,3 Prozent) heruntergerechnet, und Lücken, die BFinder gar nicht erst erkennt, fehlen in der Zählung. Außerdem gilt die Zahl nur für dokumentierte Methoden.

Generierte Suiten. Für vier der Bibliotheken (commons-cli, -codec, -compress und -jxpath) liegen Suiten von zwei Generatoren vor: von EvoSuite, einem klassischen suchbasierten Werkzeug, und von ASTER, das Tests mit Sprachmodellen erzeugt. EvoSuite lässt mindestens 20,6 Prozent der Verhaltensweisen ungeprüft, ASTER mindestens 27,1 Prozent. Die Entwicklersuiten derselben vier Projekte liegen zwischen 6,6 und 20,2 Prozent.

Zeilenabdeckung. Methoden mit 91 bis 100 Prozent Zeilenabdeckung machen bei EvoSuite 89,7 Prozent aus, bei ASTER 81,2 Prozent und bei den Entwicklersuiten über alle zehn Projekte 92,3 Prozent.

Abdeckung und Mutationsbewertung

• Zeilenabdeckung: Von den Methoden mit vollständiger Zeilenabdeckung haben 38,2 Prozent mindestens ein ungeprüftes Verhalten (Paul, Holmes, siehe oben).
• Mutationsbewertung: Von den Methoden, bei denen die Entwicklersuiten jede einzelne Mutation erkennen, haben 29,6 Prozent noch eine Lücke (Paul, Holmes).
• Minimierung nach Abdeckung: Bei Noemmer und Haas (SWQD 2020, DOI 10.1007/978-3-030-35510-4_4) strich eine Minimierung nach Anweisungsabdeckung in sieben Java-Projekten 50 bis 93 Prozent der Tests und kostete 3,5 bis 21 Prozent der relativen Mutationsbewertung, im Schnitt etwa 12,5 Prozent.
• Echte Fehlschläge: Shi und Kollegen (ISSTA 2018, DOI 10.1145/3213846.3213875) haben 1.478 fehlgeschlagene Builds aus 32 Projekten ausgewertet. Tests, die eine Reduktion nach Abdeckung oder Mutanten für überflüssig erklärt hatte, deckten dort weiterhin echte Fehler auf; ohne sie gingen 9,5 bis 52,2 Prozent der Fehlererkennung verloren.

Metas TestGen-LLM

Alshahwan et al., arXiv:2402.09171, FSE 2024.

Die drei Filter im Einzelnen. Der Kandidat muss sich bauen lassen. Er muss beim ersten Lauf bestehen und darf in fünf Ausführungen kein einziges Mal scheitern. Und er muss die Zeilenabdeckung erhöhen. Erst danach sieht ihn ein Mensch.

Ergebnis. In Metas Auswertung über 86 Testklassen von Instagram Reels und Stories hatten 75 Prozent der Klassen mindestens einen generierten Test, der sich bauen ließ, 57 Prozent einen, der zuverlässig bestand, und nur 25 Prozent einen, der zusätzlich die Zeilenabdeckung erhöhte.

Der Einwand von Simon Willison

Simon Willison, „First run the tests“, in Agentic Engineering Patterns. Dort heißt es, die alten Gründe gegen das Testen „no longer hold when an agent can knock them into shape in just a few minutes“.

Testauswahl bei Facebook

Machalica et al., arXiv:1810.05286, 2019. Das trainierte Modell wählt weniger als ein Drittel der Tests aus, die eine Auswahl nach Build-Abhängigkeiten laufen ließe, und meldet trotzdem über 99,9 Prozent der fehlerhaften Änderungen. Die Maschinenkosten fürs Testen halbierten sich. Das sind Angaben von Facebook selbst, und hinter der Auswahl liegt noch eine spätere Prüfstufe als Sicherheitsnetz.

Wie selten Projekte Tests entfernen

• Gelöschte Tests: In sieben untersuchten Java-Projekten löschen gerade einmal 0,47 Prozent aller Commits überhaupt Tests. In den sechs Projekten, die auch Produktionscode enthalten, verschwanden 91,4 Prozent der gelöschten Tests, weil ihr Produktionscode wegfiel (Bhatta, Kendemah, Jha, MSR 2025).
• Google: Das Löschwerkzeug Sensenmann entfernt nur toten Code; Tests verschwinden dort zusammen mit der Bibliothek, die sie prüfen.

Impact Mapping in der Literatur

• Gojko Adzic, David Evans, Tom Roden: Fifty Quick Ideas to Improve Your Tests. Die Autoren nennen die dritte Ebene der Impact Map, die Wirkungen bei den Akteuren, einen guten Ausgangspunkt, um darüber zu sprechen, was Nutzer mit einem System tun können, allerdings fürs explorative Testen.
• RTM (Pan, Niu, Briand, Hu, TOSEM 2026) streicht redundante Tests so, dass jede Anforderung abgedeckt bleibt.