💻 computer science

Reproduction Test Generation for Java SWE Issues

Dieser Beitrag schließt die Lücke fehlender Werkzeuge zur Generierung von Reproduktionstests für Java ein, indem er TDD-Bench-Java, den ersten Benchmark für diese Aufgabe mit 250 Instanzen aus Open-Source-Repositories, sowie e-Otter++, eine angepasste Lösung, die sowohl auf diesem Benchmark als auch auf einem proprietären Industriedatensatz eine hohe Leistungsfähigkeit zeigt, vorstellt.

Ursprüngliche Autoren: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Veröffentlicht 2026-05-07

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Software-Detektiv, der für ein riesiges Unternehmen arbeitet. Ein Benutzer meldet einen Fehler: „Hey, wenn ich auf diesen Button klicke, stürzt die App ab!" Bevor Sie den Code reparieren können, müssen Sie beweisen, dass der Fehler tatsächlich existiert. Sie schreiben ein kleines, automatisiertes Testskript, das versucht, auf diesen Button zu klicken. Wenn das Skript abstürzt, haben Sie den Fehler bestätigt. Sobald Sie den Code repariert haben, führen Sie das Skript erneut aus; wenn es nun perfekt funktioniert, wissen Sie, dass die Reparatur wirklich funktioniert hat.

Dieser Artikel handelt davon, einer KI beizubringen, diese spezifischen „Fehlersuch"-Skripte automatisch zu schreiben, aber mit einem Twist: es tut dies für Java, eine Programmiersprache, die von riesigen Unternehmen verwendet wird, während frühere KI-Tools hauptsächlich nur gut für Python funktionierten.

Hier ist die Aufschlüsselung ihrer Arbeit unter Verwendung einiger alltäglicher Analogien:

1. Das Problem: Der fehlende „Fehlersucher"

In der Welt der Software ist das Schreiben dieser Fehlersuch-Tests mühsam und wird oft übersprungen. Kürzlich ist die KI gut darin geworden, diese für Python zu schreiben (eine beliebte Sprache für Start-ups und Datenwissenschaft). Aber Java ist die „Schwerindustrie" der Unternehmenswelt (Banken, Fluggesellschaften, große Tech-Firmen). Die KI hatte mit Java Schwierigkeiten, weil es steifer und komplexer ist.

Die Autoren sagen: „Wir brauchen einen besseren Weg, um der KI beizubringen, in Java nach Fehlern zu suchen."

2. Die neue Karte: TDD-Bench-Java

Um ihre KI zu trainieren und zu testen, benötigten sie eine Karte. Sie schufen einen neuen Benchmark namens TDD-Bench-Java.

Die Analogie: Stellen Sie sich dies als einen riesigen „Fitnessstudio für KI" vor. Es enthält 250 reale Fehlerberichte von bekannten Open-Source-Java-Projekten. Jede „Einheit" besteht aus einer Fehlerbeschreibung und dem Code vor der Reparatur. Die Aufgabe der KI ist es, einen Test zu schreiben, der bei dem defekten Code fehlschlägt und bei dem reparierten Code besteht.
Warum es wichtig ist: Vorher gab es keine standardisierte Möglichkeit zu sehen, ob die KI dies tatsächlich für Java leisten kann. Dieser Benchmark ist der erste seiner Art.

3. Die Lösung: e-Otter++ (Der clevere Detektiv)

Sie nahmen einen bestehenden KI-Detektiv namens e-Otter (der großartig bei Python war) und gaben ihm ein Java-Makeover und nannten die neue Version e-Otter++.

So löst dieser KI-Detektiv einen Fall, Schritt für Schritt:

Schritt 1: Der Lokalisierer (Finden des Tatorts)
Die KI betrachtet den Fehlerbericht und die riesige Codebasis. Sie muss raten, wo sich das Problem versteckt. Es ist wie ein Detektiv, der eine Stadtkarte und eine vage Beschreibung eines Verbrechens betrachtet, um zu raten, welches spezifische Gebäude und welcher Raum zu untersuchen sind.
- Java-Twist: In Java muss man oft eine komplett neue Datei für einen Test erstellen. Die KI muss herausfinden, wo genau diese neue Datei platziert werden muss, damit sie die Struktur des Gebäudes nicht zerstört.
Schritt 2: Der Kontextualisierer (Sammeln von Hinweisen)
Sobald sie den Ort kennt, sammelt sie die richtigen Werkzeuge (Imports) und richtet die Szene ein (Paketenamen). Es ist wie ein Detektiv, der sicherstellt, dass er den richtigen Ausweis und den richtigen Grundriss hat, bevor er den Raum betritt.
Schritt 3: Der initiale Testgenerator (Der erste Versuch)
Die KI schreibt einen Entwurf für ein Testskript. Es ist eine grobe Skizze.
Schritt 4: Der Verfeinerer (Die Feedback-Schleife)
Dies ist das Geheimnis. Die KI führt ihren eigenen Test am defekten Code aus.
- Szenario A: Der Test stürzt ab, aber aus dem falschen Grund (z. B. stürzte er wegen eines Tippfehlers ab, nicht wegen des Fehlers).
- Die Reparatur: Die KI betrachtet die Fehlermeldung, erkennt ihren Fehler, schreibt den Test neu und versucht es erneut. Sie tut dies bis zu 10 Mal und lernt aus jedem Misserfolg, bis sie einen Test findet, der genau wegen des gemeldeten Fehlers abstürzt.
Schritt 5: Heterogenes Prompting (Die gleiche Frage auf 6 Arten stellen)
Um sicherzustellen, dass sie die Lösung nicht verpassen, schreibt die KI den Fehlerbericht auf sechs verschiedene Arten um (vereinfacht ihn, entfernt verwirrenden Code, fügt einen „Hinweis" hinzu usw.) und generiert sechs verschiedene Testkandidaten. Es ist wie sechs verschiedene Detektive zu bitten, denselben Fall aus verschiedenen Blickwinkeln zu lösen.
Schritt 6: Der Selektor (Den Gewinner auswählen)
Schließlich betrachtet ein „Richter"-KI alle sechs Kandidaten und wählt den einen besten Test zur Einreichung aus.

4. Die Ergebnisse: Wie gut ist es?

Im öffentlichen Fitnessstudio (TDD-Bench-Java): Die KI hatte in etwa 44 % bis 46 % der Fälle Erfolg. Das bedeutet, sie schrieb erfolgreich einen Test, der den Fehler aufdeckte und die Reparatur in fast der Hälfte der Fälle bestätigte. Dies gilt als starkes Ergebnis für eine so schwierige Aufgabe.
In der „Realität" (Proprietäre Daten): Die Autoren testeten dies auch an 150 Fehlern aus ihrem eigenen privaten Unternehmen (IBM).
- Die Herausforderung: Diese Fehler waren schwieriger. Die Beschreibungen waren kürzer, vager und beinhalteten oft das Erstellen brandneuer Dateien, die noch nicht existierten.
- Das Ergebnis: Ohne Hilfe hatte die KI nur in 4 % der Fälle Erfolg.
- Die Reparatur: Als sie der KI einen „Hinweis" gaben (ihre sagten ihr die Namen der neuen Dateien, die sie erstellen musste), stieg die Erfolgsrate auf 20 %.

5. Das Fazit

Die Studie kommt zu dem Schluss, dass die KI zwar besser darin wird, Fehlersuch-Tests für Java zu schreiben, aber immer noch mit der chaotischen, vagen Realität von Unternehmenssoftware zu kämpfen hat, im Vergleich zu den saubereren Daten, die in Open-Source-Projekten zu finden sind.

Kurz gesagt: Sie bauten einen neuen Trainingsplatz (TDD-Bench-Java) und einen klügeren Detektiv (e-Otter++), der nun nach Fehlern in Java-Code suchen kann. Es funktioniert gut bei Standardproblemen, braucht aber immer noch ein wenig menschliche Hilfe (Hinweise), wenn die Hinweise vage sind oder der Code brandneu ist.

Technische Zusammenfassung: Generierung von Reproduktionstests für Java-SWE-Probleme

Problemstellung

Die Arbeit adressiert die kritische Lücke in der automatisierten Softwareentwicklung (SWE) für Java: die Generierung von Reproduktionstests. Ein Reproduktionstest wird definiert als ein Test, der auf der aktuellen Codebasis fehlschlägt (was das Vorhandensein eines Problems bestätigt) und nach der Behebung des Problems besteht (was dessen Abwesenheit bestätigt). Während jüngste Fortschritte Benchmarks und Lösungen für Python hervorgebracht haben, bleibt Java trotz seiner Dominanz in der Unternehmenssoftware unterversorgt. Bestehende Java-spezifische Tools verfügen entweder nicht über Fähigkeiten zur Fehlerlokalisierung, verlassen sich auf vereinfachte Problemvarianten oder leiden unter Datenkontamination und Überanpassung. Darüber hinaus unterscheiden sich Enterprise-Java-Fehler oft in ihrer Verteilung und Komplexität von Open-Source-Python-Fehlern, was spezialisierte Ansätze erfordert, die das statische Typsystem und die objektorientierte Natur von Java berücksichtigen.

Methodik

Die Autoren schlagen e-Otter++ für Java vor, eine Anpassung eines state-of-the-art Python-Reproduktionstest-Generators. Die Methodik ist eine mehrstufige Pipeline, die entwickelt wurde, um Komplexität auf Repository-Ebene zu bewältigen, ohne während der Generierung Zugriff auf den Korrekturcode ( $c_{new}$ ) zu benötigen.

1. Pipeline-Architektur

Der Workflow besteht aus vier Hauptkomponenten:

Lokalisierer: Identifiziert „fokale Funktionen" (die wahrscheinlich modifiziert werden) und zugehörige Regressionstests. Im Gegensatz zur Python-Version, die diese Aufgaben trennte, werden sie in der Java-Version zu einem einzigen Schritt zusammengefasst, um die höhere Häufigkeit neuer Testdateien in Java-Projekten zu bewältigen. Es wird ein dreistufiger LLM-Prozess verwendet: Auswählen relevanter Dateien nach Name, Auswählen von Funktionen nach Name und schließlich Filtern basierend auf Funktionskörpern.
Kontextualisierer: Erstellt das notwendige Gerüst für eine neue Testdatei, was in Java üblich ist. Er bestimmt den korrekten Paketnamen, die Imports und den Dateipfad, indem er das Repository abfragt und aus vorhandenen Optionen auswählt, um Halluzinationen zu minimieren.
Initialer Test-Generator: Generiert einen initialen Testkandidaten ( $t_{ot}$ ) als neue Klasse in einer neuen Datei, angeregt durch die Problembeschreibung und den lokalisierten Kontext.
Verfeinerer: Verbessert den Test iterativ unter Verwendung von Ausführungsfeedback. Er führt den Test auf dem alten Code ( $c_{old}$ ) aus, analysiert die Protokolle über einen LLM-basierten Kritiker und schreibt den Test um, wenn er aus dem falschen Grund fehlschlägt. Diese Schleife läuft bis zu 10 Mal und akkumuliert Änderungen, um wiederholte Fehler zu verhindern.

2. Skalierung der Inferenz durch Heterogenes Prompting

Um die Vielfalt der Testkandidaten zu erhöhen, setzt das System heterogenes Prompting ein, anstatt auf Temperatur-basiertem Sampling zu beruhen. Die Problembeschreibung wird in sechs verschiedene Varianten (Morphs) umgeschrieben:

Standard: Umformulierung in ein strukturiertes Format.
Einfach: Entfernen von Fachjargon und Vereinfachung des Textes.
dropCode: Entfernen potenziell irreführender Code-Snippets.
initTest: Einbeziehen eines generierten initialen Tests in das Prompt.
initPatch: Einbeziehen eines vorgeschlagenen Code-Patches in das Prompt.
Standard: Verwendung der ursprünglichen Problembeschreibung.

Ein Test-Selektor bewertet dann die sechs resultierenden Kandidaten (zusammen mit ihren Ausführungsprotokollen) und wählt den besten einzelnen Test zur Einreichung aus.

Hauptbeiträge

TDD-Bench-Java: Der erste Benchmark auf Repository-Ebene speziell für die Generierung von Java-Reproduktionstests. Er umfasst 250 Instanzen aus beliebten Open-Source-Repositories (z. B. Trino, Jackson, RocketMQ), die gefiltert wurden, um ein „Fail-to-Pass"-Verhalten sicherzustellen. Der Datensatz enthält diverse Build-Tools (Maven, Gradle) und Projektstrukturen.
e-Otter++ für Java: Eine robuste Lösung, die aus Python-Workflows adaptiert wurde und hohe Leistung auf dem neuen Benchmark erzielt. Es ist die erste vollständige Lösung für die Generierung von Java-Reproduktionstests auf Repository-Ebene, die Fehlerlokalisierung einschließt.
Proprietäre Industrie-Evaluation: Die Arbeit evaluiert das System an einem kontaminationsfreien proprietären Datensatz mit 150 Problemen aus einem internen IBM-Java-Projekt. Dies liefert Einblicke in die Herausforderungen der Anwendung dieser Modelle auf reale Unternehmenscodebasen, die sich oft erheblich von Open-Source-Daten unterscheiden.

Ergebnisse

Öffentlicher Benchmark (TDD-Bench-Java)

Unter Verwendung der Modelle Claude-Sonnet-4.5 und GPT-5.2 erreichte e-Otter++:

43,6 % Fail-to-Pass-Rate mit Claude-Sonnet-4.5.
46,4 % Fail-to-Pass-Rate mit GPT-5.2.

Wichtige Erkenntnisse:

Auswirkung der Verfeinerung: Der Verfeinerungsschritt (e-Otter) verbesserte die Leistung gegenüber dem initialen Generator (Otter) erheblich, mit relativen Verbesserungen zwischen 26,2 % und 64,3 %, je nach Modell und Morph.
Heterogenes Prompting: Die Verwendung von sechs Morphs erhöhte die Fail-to-Pass-Rate bei N=6 (mindestens ein Kandidat erfolgreich) um mehr als 32 % im Vergleich zu Ansätzen mit einer einzigen Variante.
Statistische Signifikanz: McNemar-Tests bestätigten, dass die Verbesserungen von Otter zu e-Otter statistisch signifikant waren ( $p < 0,01$ ).

Ergebnisse des proprietären Datensatzes

Die Leistung auf dem internen IBM-Datensatz war niedriger und unterstrich die Schwierigkeit von Unternehmenscode:

Standard-Leistung: Bei Standard-Problembeschreibungen lag die Fail-to-Pass-Rate bei nur 4 % (6/150).
Mit Hinweisen: Wenn dem System „Hinweise" bereitgestellt wurden (neue Klassennamen und Funktionssignaturen, die aus dem Code-Patch abgeleitet wurden), verbesserte sich die Rate auf 20 % (30/150).
Datenmerkmale: Proprietäre Probleme waren kürzer, enthielten keine Code-Snippets und betrafen signifikant größere Code-Patches (durchschnittlich 362 Zeilen gegenüber 55 Zeilen in öffentlichen Daten). Darüber hinaus waren 84 % der proprietären Probleme Feature-Anfragen statt Fehlerbehebungen, die oft neue Dateien einführten, die Modelle schwer vorherzusagen können.

Bedeutung und Behauptungen

Die Arbeit behauptet, einen bedeutenden Beitrag zum Feld zu leisten durch:

Überbrückung der Sprachlücke: Bereitstellung des ersten dedizierten Benchmarks und der ersten Lösung für Java, einer für Unternehmenssoftware kritischen Sprache, die in der Forschung zur Generierung von Reproduktionstests bisher vernachlässigt wurde.
Industrierelevanz: Überwindung von Open-Source-Benchmarks, um die Leistung an proprietären Daten zu evaluieren, was zeigt, dass Modelle zwar auf kuratierten öffentlichen Daten gut abschneiden, aber erhebliche Herausforderungen mit dem „Rauschen" und der Komplexität realer Unternehmensprobleme (z. B. kurze Beschreibungen, Generierung neuer Dateien) konfrontiert sind.
Methodische Strenge: Demonstration, dass Skalierung der Inferenz durch heterogenes Prompting und ausführungsgesteuerte Verfeinerung effektive Strategien für Java sind, selbst wenn das statische Typsystem Build-Zeit-Fehler einführt, die sich von Python-Laufzeitfehlern unterscheiden.

Die Autoren schließen, dass zwar aktuelle LLM-basierte Ansätze vielversprechend sind, die Zuverlässige Diagnose und Validierung in der Java-Softwareentwicklung jedoch weitere Innovationen erfordert, insbesondere im Umgang mit schlecht spezifizierten Problemen und der Generierung genauer Kontexte für neue Code-Strukturen.