💻 computer science

Hallucination to Consensus: Multi-Agent LLMs for End-to-End JUnit Test Generation

Dit artikel introduceert CANDOR, een innovatief framework dat gebruikmaakt van meerdere gespecialiseerde LLM-agenten en een consensusstrategie om automatisch hoogwaardige JUnit-tests voor Java te genereren met een aanzienlijk hogere correctheid en mutatiescore dan bestaande methoden zoals EvoSuite en TOGLL.

Oorspronkelijke auteurs: Qinghua Xu, Guancheng Wang, Lionel Briand, Kui Liu

Gepubliceerd 2026-03-27

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Qinghua Xu, Guancheng Wang, Lionel Briand, Kui Liu

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 groot, complex gebouwtje (software) bouwt. Voordat je het aan de wereld presenteert, moet je zeker weten dat de deuren niet vastzitten, dat het dak niet lekt en dat de lift werkt. In de programmeerwereld noemen we dit unit testing: het testen van kleine stukjes code om fouten te vinden voordat ze problemen veroorzaken.

Het probleem? Het handmatig schrijven van deze tests is als het bouwen van een tweede, perfecte kopie van je huis, alleen om te zien of het eerste huis stabiel is. Het is saai, tijdrovend en veel programmeurs slaan het over.

De auteurs van dit paper hebben een nieuwe oplossing bedacht, genaamd CANDOR. Ze gebruiken kunstmatige intelligentie (LLMs) om deze tests automatisch te schrijven. Maar ze hebben een slimme twist toegevoegd om de problemen van AI op te lossen.

Hier is hoe het werkt, vertaald naar een eenvoudig verhaal:

1. Het Probleem: De "Hallucinerende" AI

Stel je voor dat je een AI vraagt om een test te schrijven. De AI is slim, maar ze heeft een gewoonte: ze hallucineert. Ze zegt dingen die klinken als waarheid, maar die helemaal niet kloppen.

Voorbeeld: Als je vraagt of een getal even is, zegt de AI misschien: "Ja, want 3 is een even getal." Ze denkt dat ze gelijk heeft, maar ze maakt een fout.
In het verleden probeerden andere systemen dit op te lossen door de AI te "trainen" op duizenden voorbeelden (zoals een student die maanden studeert). Maar dat is duur, traag en werkt niet goed als je nieuwe programmeertalen gebruikt.

2. De Oplossing: Een Panel van Experts (CANDOR)

CANDOR lost dit op door niet één AI te gebruiken, maar een team van gespecialiseerde AI-agenten die samenwerken. Het is alsof je een jury hebt in plaats van één rechter.

Het proces verloopt in drie stappen, zoals een bouwproject:

Stap 1: De Sloop en de Fundering (Initialisatie)

Eerst maakt een AI-agent (de Initializer) een ruwe schets van de test. Vaak zit hier nog veel rommel in (foutieve code). Een andere agent (de Validator) controleert of de schets wel werkt. Als er fouten zijn, krijgt de eerste agent een seintje: "Hé, dit klopt niet, probeer het opnieuw." Dit gaat door tot er een stevige, werkende basis ligt.

Stap 2: Het Bouwen van de Test (Test Prefix Generation)

Nu moet de test uitgebreid worden. Een Planner (een strateeg) kijkt welke delen van het gebouw nog niet getest zijn en zegt: "We moeten een test maken voor de trap." Een Tester (de bouwer) bouwt die test. Een Inspector (de bouwmeester) loopt er langs om te kijken of alles veilig is.

Het gevaar: Als de originele code (het gebouw) een fout heeft, bouwt de AI de test op basis van die fout. De test zegt dan: "Ja, de trap is veilig," terwijl de trap eigenlijk instort. De AI neemt de fout van de programmeur over.

Stap 3: De "Panel Discussie" (Oracle Fixing) - De Magie

Dit is het belangrijkste nieuwe idee van het paper. Om de fouten in de originele code te corrigeren, roepen ze een Panel bijeen.

De Panelisten: Drie verschillende AI's (de "Panelisten") lezen de instructies van de programmeur (wat het programma moet doen) en kijken naar de test. Ze discussiëren onderling.
- Panelist 1: "Ik denk dat de uitkomst 27 moet zijn."
- Panelist 2: "Nee, wacht even. Als ik de regels goed lees, moet het 147 zijn."
- Panelist 3: "Ik ben het met 2 eens. De originele code was fout, maar de test moet de bedoeling van de programmeur volgen, niet de fout."
De Curator: Een vierde AI (de Curator) luistert naar deze discussie. In plaats van gewoon te tellen wie er het vaakst gelijk heeft (meerderheidsstem), kijkt deze AI naar de redenering. Als twee panelisten dezelfde goede logica hebben, neemt de Curator hun conclusie over.
Het resultaat: De fout in de originele code wordt genegeerd, en de test krijgt de juiste, correcte uitkomst.

3. Waarom is dit zo slim? (De Analogie van de "Overdenker")

Soms zijn de slimste AI's (de "Redenerende AI's") te druk met nadenken. Ze zeggen: "Het antwoord is 147... maar wacht, misschien is het 27? Nee, 147... maar wat als...?" Ze worden zo langdradig dat het uren duurt om hun antwoord te krijgen.

CANDOR gebruikt een slimme truc:

De "Overdenker" (de Redenerende AI) denkt hard na en schrijft een heel lang verhaal.
Een "Vertaler" (een simpele AI) leest dit lange verhaal en haalt alleen het korte, duidelijke antwoord eruit.
De "Curator" neemt dat korte antwoord en vergelijkt het met de anderen.

Dit bespaart tijd en voorkomt dat de AI in een denkkrans terechtkomt.

Wat zeggen de resultaten?

De auteurs hebben CANDOR getest op twee grote verzamelingen programmeeropdrachten:

EvoSuite (de huidige kampioen in het bouwen van tests) is heel goed in het vinden van code die wordt gebruikt (dekking), maar minder goed in het vinden van subtiele fouten.
CANDOR is net zo goed in het vinden van code, maar veel beter in het vinden van fouten (mutaties).
De grootste overwinning: Waar andere systemen (zoals TOGLL) de originele fouten van de code overnamen, vond CANDOR de fouten en schreef de juiste test. Het was 21% beter in het vinden van de juiste uitkomsten dan de beste bestaande systemen, zelfs zonder dat ze eerst maandenlang moesten worden getraind.

Conclusie

CANDOR is als het hebben van een team van slimme, kritische collega's die samenwerken om een test te schrijven. Ze laten elkaar niet hallucineren, ze discussiëren hun fouten weg, en ze zorgen ervoor dat de test klopt met wat de programmeur bedoelde, niet met wat de programmeur per ongeluk gemaakt heeft.

Het is een stap in de richting van software die zichzelf test, zodat wij programmeurs minder tijd hoeven te besteden aan het zoeken naar fouten en meer tijd hebben om te bouwen.

Probleemstelling

Het handmatig schrijven van unit-tests is tijdrovend en vereist specifieke domeinkennis, wat vaak leidt tot onvoldoende testdekking in softwareprojecten. Bestaande geautomatiseerde methoden kampen met twee belangrijke beperkingen:

Test Prefixes (Inputgeneratie): Traditionele zoekgebaseerde methoden (zoals EvoSuite) genereren vaak tests met hoge code-dekking, maar de gegenereerde tests zijn weinig leesbaar en missen semantische betekenis. LLM-gebaseerde benaderingen verbeteren de leesbaarheid, maar halen vaak niet de dekking van traditionele tools.
Test Oracles (Asserties): De meeste methoden genereren "regression oracles" die het huidige (mogelijk defecte) gedrag van de code vastleggen in plaats van de beoogde functionaliteit. Het genereren van correcte "specification-based oracles" (gebaseerd op eisen) is complex, vooral in sterk getypeerde talen zoals Java. Bestaande LLM-oplossingen vereisen vaak dure fine-tuning of zijn afhankelijk van externe tools die verouderd zijn. Daarnaast lijden LLMs aan "hallucinaties" (het genereren van plausibele maar onjuiste informatie) en een "overthinking"-fenomeen (onnodig lange en redundante redeneringen).

Methodologie: CANDOR

De auteurs stellen CANDOR voor, een nieuw end-to-end framework dat gebruikmaakt van Multi-Agent LLMs en Prompt Engineering om JUnit-tests te genereren zonder fine-tuning. Het framework werkt in drie stappen:

Initialisatie (Step I):
- Een Initializer-agent genereert een eerste, syntactisch correct testbestand op basis van de broncode.
- Een validatieproces compilaat en executeert de code. Bij fouten wordt feedback gegeven aan de Initializer voor herhaling totdat een geldig bestand ( $v_1$ ) is gegenereerd.
Generatie van Test Prefixes (Step II):
- Dit stap focust op het verhogen van de code-dekking.
- Een Planner-agent analyseert de dekking en stelt testplannen op.
- Een Tester-agent genereert de daadwerkelijke testcode op basis van deze plannen.
- Een Inspector-agent controleert de gegenereerde code op fouten en geeft feedback.
- Dit proces is iteratief en resulteert in een testbestand ( $v_2$ ) met hoge dekking, maar de asserties (oracles) zijn nog steeds "tijdelijk" en mogelijk onjuist als de broncode fouten bevat.
Correctie van Oracles (Step III - De Kerninnovatie):
- Om hallucinaties en onjuiste oracles te corrigeren, wordt een Panel Discussion-strategie ingevoerd, geïnspireerd op het idee dat "waarheid voortkomt uit argumenten tussen vrienden".
- Requirement Engineer: Extraheert eisen en formele specificaties uit de natuurlijke taalbeschrijving van de code.
- Dual-LLM Pipelines: Meerdere Panelist-agents (krachtige redenerende LLMs, zoals DeepSeek R1) evalueren onafhankelijk de tijdelijke oracles tegen de eisen. Om het "overthinking"-probleem op te lossen, wordt elke Panelist gekoppeld aan een Interpreter-agent (een simpele LLM) die de lange redeneringen samenvat tot beknopte, gestructureerde oordelen.
- Curator: Deze agent verzamelt de oordelen van alle panelleden, analyseert de redeneringen en bereikt een consensus om de definitieve, correcte oracle te genereren. Dit vermindert hallucinaties door cross-validatie.

Belangrijkste Bijdragen

Eerste Multi-Agent Framework: CANDOR is het eerste framework dat uitsluitend gebruikmaakt van kant-en-klare (off-the-shelf) LLMs voor end-to-end JUnit-testgeneratie in Java, zonder afhankelijkheid van verouderde tools zoals EvoSuite of kostbare fine-tuning.
Consensus-strategie: Een innovatieve aanpak waarbij meerdere redenerende agents in een "panel discussion" samenwerken om hallucinaties te minimaliseren en de nauwkeurigheid van testoracles te maximaliseren.
Dual-LLM Pipeline: Een nieuwe methode om de verbaaliteit van redenerende LLMs te beheersen door hun output te laten interpreteren door een simpele agent, wat de efficiëntie verhoogt zonder in te leveren op de kwaliteit van de redenering.
Uitgebreide Validatie: Toepassing op twee datasets: HumanEvalJava en een nieuw, complexer dataset LeetCodeJava (met variërende moeilijkheidsgraden).

Resultaten

De experimenten tonen aan dat CANDOR presteert als volgt:

Test Prefix Kwaliteit: CANDOR bereikt een code-dekking (line en branch coverage) die vergelijkbaar is met de state-of-the-art tool EvoSuite, maar significant beter dan andere LLM-benaderingen (zoals LLM-Empirical).
Mutation Score: CANDOR presteert significant beter dan EvoSuite in het detecteren van fouten (mutation score), wat wijst op tests met een hogere semantische kwaliteit en betere bug-detectie.
Oracle Nauwkeurigheid:
- CANDOR overtreft de state-of-the-art fine-tuning methode TOGLL met minimaal 21,1 procentpunten in nauwkeurigheid van de oracles, zowel voor correcte als defecte broncode.
- Dit is opmerkelijk omdat TOGLL is gefinetuned op extra data, terwijl CANDOR alleen prompt engineering gebruikt.
- De methode is robuust tegen defecte broncode omdat de oracles worden afgeleid van de natuurlijke taalbeschrijving en niet alleen van de implementatie.
Ablatie Studies:
- Het verwijderen van de Planner leidt tot een sterke daling in dekking.
- Het verwijderen van de Panel Discussion (en het vervangen door simpel stemmen) leidt tot een significante daling in oracle-nauwkeurigheid, wat het belang van de consensus-mechanisme bevestigt.

Betekenis en Impact

Dit paper biedt een doorbraak in geautomatiseerd testen voor Java door:

De afhankelijkheid van dure fine-tuning en verouderde zoekalgoritmen te doorbreken.
Een praktische oplossing te bieden voor het genereren van specification-based oracles, wat essentieel is voor het valideren van functionaliteit in plaats van alleen het detecteren van regressies.
Een bewijs te leveren dat multi-agent systemen met consensus-mechanismen hallucinaties in LLMs effectief kunnen mitigeren, zelfs in complexe, sterk getypeerde programmeertalen.
Een schaalbare en flexibele aanpak te bieden die makkelijk aanpasbaar is aan nieuwe Java-versies en ontwikkelomgevingen, zonder dat er nieuwe datasets voor training nodig zijn.

Kortom, CANDOR stelt een nieuwe standaard voor end-to-end testgeneratie die zowel de dekking als de semantische kwaliteit van tests aanzienlijk verbetert.