💻 computer science

Reproduction Test Generation for Java SWE Issues

Dit artikel adresseert het gebrek aan tools voor het genereren van reproduceerbaarheidstests voor Java door TDD-Bench-Java in te voeren, de eerste benchmark voor deze taak met 250 instances uit open-source repositories, en e-Otter++, een aangepaste oplossing die hoge prestaties demonstreert op zowel deze benchmark als een proprietair industriële dataset.

Oorspronkelijke auteurs: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Gepubliceerd 2026-05-07

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een software-detective bent die werkt voor een enorm bedrijf. Een gebruiker meldt een bug: "Hé, als ik op deze knop klik, crasht de app!" Voordat je de code kunt repareren, moet je bewijzen dat de bug echt bestaat. Je schrijft een klein, geautomatiseerd testscript dat probeert op die knop te klikken. Als het script crasht, heb je de bug bevestigd. Zodra je de code hebt gerepareerd, voer je het script opnieuw uit; als het nu perfect werkt, weet je dat de reparatie echt is.

Dit artikel gaat over het leren aan een AI om die specifieke "bug-jacht"-scripts automatisch te schrijven, maar met een draai: het doet dit voor Java, een programmeertaal die door grote bedrijven wordt gebruikt, terwijl eerdere AI-tools voornamelijk alleen goed werkten voor Python.

Hier is de uiteenzetting van hun werk met behulp van alledaagse analogieën:

1. Het Probleem: De Ontbrekende "Bug-jager"

In de wereld van software is het schrijven van deze bug-jacht-tests saai en wordt het vaak overgeslagen. Onlangs is AI goed geworden in het schrijven ervan voor Python (een populaire taal voor startups en data science). Maar Java is de "zware machines" van de zakelijke wereld (banken, luchtvaartmaatschappijen, grote tech-bedrijven). De AI had moeite met Java omdat het stijver en complexer is.

De auteurs zeggen: "We hebben een betere manier nodig om AI te leren bugs te jagen in Java."

2. De Nieuwe Kaart: TDD-Bench-Java

Om hun AI te trainen en te testen, hadden ze een kaart nodig. Ze creëerden een nieuwe benchmark genaamd TDD-Bench-Java.

De Analogie: Denk hierbij aan een grote "Sportschool voor AI". Het bevat 250 echte bugrapporten van beroemde open-source Java-projecten. Elke "workout" bestaat uit een bugbeschrijving en de code voor de reparatie. De taak van de AI is om een test te schrijven die faalt op de gebroken code en slaagt op de gerepareerde code.
Waarom dit belangrijk is: Voorheen was er geen gestandaardiseerde manier om te zien of AI dit echt kon voor Java. Deze benchmark is de eerste in zijn soort.

3. De Oplossing: e-Otter++ (De Slimme Detective)

Ze namen een bestaande AI-detective genaamd e-Otter (die geweldig was in Python) en gaven het een Java-make-over, de nieuwe versie e-Otter++ noemend.

Hier is hoe deze AI-detective een zaak oplost, stap voor stap:

Stap 1: De Lokalisator (Het vinden van de plaats delict)
De AI kijkt naar het bugrapport en de enorme codebase. Het moet raden waar het probleem zich verbergt. Het is als een detective die naar een stadskaart en een vaag beschrijving van een misdaad kijkt om te raden welk specifiek gebouw en welke kamer ze moeten onderzoeken.
- Java-draai: In Java moet je vaak een heel nieuw bestand maken voor een test. De AI moet precies uitzoeken waar dit nieuwe bestand moet worden geplaatst zodat het de structuur van het gebouw niet verstoort.
Stap 2: De Contextualisator (Het verzamelen van aanwijzingen)
Zodra het de locatie kent, verzamelt het de juiste hulpmiddelen (imports) en stelt het de scène in (pakketnamen). Het is als een detective die ervoor zorgt dat ze het juiste badge en het juiste plattegrond hebben voordat ze de kamer binnenkomen.
Stap 3: De Initiële Testgenerator (Het maken van de eerste poging)
De AI schrijft een concept-testscript. Het is een ruwe schets.
Stap 4: De Verfijner (De feedbacklus)
Dit is het geheim. De AI voert zijn eigen test uit op de gebroken code.
- Scenario A: De test crasht, maar om de verkeerde reden (bijvoorbeeld: het crashte vanwege een typefout, niet vanwege de bug).
- De Reparatie: De AI kijkt naar het foutbericht, realiseert zich zijn fout, herschrijft de test en probeert het opnieuw. Het doet dit tot 10 keer, leert van elke mislukking, totdat het een test vindt die crasht exact vanwege de gerapporteerde bug.
Stap 5: Heterogene Prompting (Hetzelfde vraag 6 manieren stellen)
Om ervoor te zorgen dat ze de oplossing niet missen, herschrijft de AI het bugrapport op zes verschillende manieren (het vereenvoudigen, verwarrende code verwijderen, een "hint" toevoegen, enz.) en genereert zes verschillende testkandidaten. Het is als het vragen aan zes verschillende detectives om dezelfde zaak op te lossen met verschillende invalshoeken.
Stap 6: De Selecteur (De winnaar kiezen)
Ten slotte kijkt een "Rechter"-AI naar alle zes kandidaten en kiest de enige beste test om in te dienen.

4. De Resultaten: Hoe goed is het?

Op de Publieke Sportschool (TDD-Bench-Java): De AI slaagde ongeveer 44% tot 46% van de tijd. Dit betekent dat het succesvol een test schreef die de bug ving en de reparatie bevestigde in bijna de helft van de gevallen. Dit wordt beschouwd als een sterk resultaat voor zo'n moeilijke taak.
Op de "Wereld van de Realiteit" (Propriëtaire Data): De auteurs testten dit ook op 150 bugs van hun eigen privébedrijf (IBM).
- De Uitdaging: Deze bugs waren moeilijker. De beschrijvingen waren korter, vager en hielden vaak het maken van gloednieuwe bestanden in die nog niet bestonden.
- Het Resultaat: Zonder hulp slaagde de AI slechts 4% van de tijd.
- De Reparatie: Toen ze de AI een "hint" gaven (waarmee ze de namen van de nieuwe bestanden vertelden die ze moesten maken), steeg het slagingspercentage naar 20%.

5. De Conclusie

Het artikel concludeert dat hoewel AI beter wordt in het schrijven van bug-jacht-tests voor Java, het nog steeds worstelt met de rommelige, vage realiteit van zakelijke software in vergelijking met de schonere data die in open-source-projecten wordt gevonden.

Kortom: Ze bouwden een nieuwe trainingsgrond (TDD-Bench-Java) en een slimme detective (e-Otter++) die nu bugs kan jagen in Java-code. Het werkt goed bij standaardproblemen, maar heeft nog steeds een beetje menselijke hulp (hints) nodig wanneer de aanwijzingen vaag zijn of de code gloednieuw is.

Technische Samenvatting: Generatie van Reproductietests voor Java SWE-problemen

Probleemstelling

Het artikel adresseert het kritieke gat in geautomatiseerde software-engineering (SWE) voor Java: de generatie van reproductietests. Een reproductietest wordt gedefinieerd als een test die faalt op de huidige codebase (wat het bestaan van een probleem bevestigt) en slaagt nadat het probleem is opgelost (wat de afwezigheid ervan bevestigt). Hoewel recente vooruitgang benchmarks en oplossingen voor Python heeft opgeleverd, blijft Java onderbediend ondanks zijn dominantie in enterprise-software. Bestaande op Java gerichte tools missen ofwel fault-localisatiecapaciteiten, vertrouwen op vereenvoudigde varianten van problemen, of lijden aan datasetvervuiling en overfitting. Bovendien verschillen enterprise-Java-bugs vaak in distributie en complexiteit van open-source-Python-bugs, wat gespecialiseerde benaderingen vereist die rekening houden met het statische typesysteem en de objectgeoriënteerde aard van Java.

Methodologie

De auteurs stellen e-Otter++ voor Java voor, een aanpassing van een state-of-the-art Python-reproductietestgenerator. De methodologie is een meerstaps-pijplijn die is ontworpen om repository-niveau complexiteit te hanteren zonder toegang tot de fix-code ( $c_{new}$ ) tijdens de generatie.

1. Pijplijnarchitectuur

De workflow bestaat uit vier primaire componenten:

Localizer: Identificeert "focale functies" (waarschijnlijk te wijzigen) en gerelateerde regressietests. In tegenstelling tot de Python-versie, waarbij deze taken gescheiden waren, worden ze in de Java-versie samengevoegd tot één stap om de hogere frequentie van nieuwe testbestanden in Java-projecten te hanteren. Het gebruikt een drie-staps LLM-proces: selecteren van relevante bestanden op naam, selecteren van functies op naam, en uiteindelijk filteren op basis van functielichamen.
Contextualizer: Construeert de noodzakelijke steiger voor een nieuw testbestand, wat gebruikelijk is in Java. Het bepaalt de juiste pakketnaam, imports en bestandspad door de repository te bevragen en te kiezen uit bestaande opties om hallucinaties te minimaliseren.
Initiële Testgenerator: Genereert een initiële testkandidaat ( $t_{ot}$ ) als een nieuwe klasse in een nieuw bestand, geprompt met de probleemomschrijving en gelokaliseerde context.
Refiner: Verbetert de test iteratief met behulp van uitvoeringsfeedback. Het voert de test uit op de oude code ( $c_{old}$ ), analyseert de logs via een LLM-gebaseerde criticus, en herschrijft de test als deze om de verkeerde reden faalt. Deze lus loopt maximaal 10 keer, waarbij wijzigingen worden opgeteld om repetitieve fouten te voorkomen.

2. Inference Scaling via Heterogene Prompting

Om de diversiteit van testkandidaten te vergroten, maakt het systeem gebruik van heterogene prompting in plaats van temperatuur-gebaseerde sampling. De probleemomschrijving wordt herschreven tot zes distincte varianten (morphs):

Standaard: Herschrijven naar een gestructureerd formaat.
Eenvoudig: Jargon verwijderen en de tekst vereenvoudigen.
dropCode: Potentieel misleidende codefragmenten verwijderen.
initTest: Een gegenereerde initiële test opnemen in de prompt.
initPatch: Een voorgestelde codepatch opnemen in de prompt.
Standaard: De originele probleemomschrijving gebruiken.

Een Test Selector evalueert vervolgens de zes resulterende kandidaten (samen met hun uitvoeringslogs) en selecteert de enige beste test voor indiening.

Belangrijkste Bijdragen

TDD-Bench-Java: De eerste repository-niveau benchmark specifiek voor Java-reproductietestgeneratie. Deze omvat 250 instances afkomstig van populaire open-source repositories (bijv. Trino, Jackson, RocketMQ), gefilterd om "fail-to-pass"-gedrag te garanderen. De dataset omvat diverse buildtools (Maven, Gradle) en projectstructuren.
e-Otter++ voor Java: Een robuuste oplossing aangepast van Python-workflows, die hoge prestaties behaalt op de nieuwe benchmark. Het is de eerste complete oplossing voor repository-niveau Java-reproductietestgeneratie die fault-localisatie omvat.
Propriëtaire Industrie-evaluatie: Het artikel evalueert het systeem op een vervuilingsvrije, propriëtaire dataset van 150 problemen uit een intern IBM-Javaproject. Dit biedt inzichten in de uitdagingen van het toepassen van deze modellen op echte enterprise-code, die vaak aanzienlijk verschilt van open-source data.

Resultaten

Publieke Benchmark (TDD-Bench-Java)

Met behulp van de Claude-Sonnet-4.5 en GPT-5.2 modellen behaalde e-Otter++:

43,6% fail-to-pass-rate met Claude-Sonnet-4.5.
46,4% fail-to-pass-rate met GPT-5.2.

Belangrijkste Bevindingen:

Impact van Verfijning: De verfijningstap (e-Otter) verbeterde de prestaties aanzienlijk ten opzichte van de initiële generator (Otter), met relatieve verbeteringen variërend van 26,2% tot 64,3% afhankelijk van het model en de morph.
Heterogene Prompting: Het gebruik van zes morphs verhoogde de fail-to-pass-rate bij N=6 (minstens één kandidaat slaagt) met meer dan 32% in vergelijking met benaderingen met één variant.
Statistische Significantie: McNemar-tests bevestigden dat de verbeteringen van Otter naar e-Otter statistisch significant waren ( $p < 0,01$ ).

Resultaten Propriëtaire Dataset

De prestaties op de interne IBM-dataset waren lager, wat de moeilijkheid van enterprise-code benadrukt:

Standaard Prestaties: Met standaard probleemomschrijvingen was de fail-to-pass-rate slechts 4% (6/150).
Met Hints: Wanneer het systeem "hints" kreeg (nieuwe klassennamen en functiesignaturen afgeleid van de codepatch), verbeterde het percentage naar 20% (30/150).
Data-eigenschappen: Propriëtaire problemen waren korter, misten codefragmenten en betroffen aanzienlijk grotere codepatches (gemiddeld 362 regels versus 55 regels in publieke data). Bovendien waren 84% van de propriëtaire problemen feature-aanvragen in plaats van bugfixes, waarbij vaak nieuwe bestanden werden geïntroduceerd die modellen moeite hebben te anticiperen.

Betekenis en Claims

Het artikel claimt een aanzienlijke bijdrage te leveren aan het vakgebied door:

De Taalgat te Overbruggen: Het bieden van de eerste toegewijde benchmark en oplossing voor Java, een taal die cruciaal is voor enterprise-software maar eerder verwaarloosd werd in onderzoek naar reproductietestgeneratie.
Industrie-relevantie: Voorbijgaan aan open-source benchmarks om prestaties te evalueren op propriëtaire data, wat blootlegt dat hoewel modellen goed presteren op gecureerde publieke data, ze aanzienlijke uitdagingen ondervinden met de "ruis" en complexiteit van echte enterprise-problemen (bijv. korte beschrijvingen, generatie van nieuwe bestanden).
Methodologische Strenge: Aantonen dat inference scaling via heterogene prompting en uitvoeringsgestuurde verfijning effectieve strategieën zijn voor Java, zelfs wanneer het statische typesysteem build-time fouten introduceert die verschillen van Python's runtime-fouten.

De auteurs concluderen dat hoewel huidige op LLM-gebaseerde benaderingen veelbelovend zijn, het brengen van betrouwbare diagnose en validatie naar Java-softwareontwikkeling verdere innovatie vereist, met name bij het hanteren van slecht gespecificeerde problemen en het genereren van accurate context voor nieuwe codestructuren.