Stel je voor dat je een meesterkok bent die probeert een zeer getalenteerde, maar licht chaotische sous-chef te leren hoe hij een perfect gerecht bereidt. Je geeft de sous-chef een recept (de code) en vraagt hem om een "smaaktest" (een unit test) te schrijven om te bewijzen dat het gerecht werkt. In de wereld van software zijn deze "smaaktests" kleine programmaatjes die controleren of een specifiek stuk code doet wat het moet doen. Jarenlang hebben mensen deze tests met de hand geschreven, maar dat is een tijdrovende klus. Onlangs zijn we begonnen met het gebruik van Kunstmatige Intelligentie, specifiek Large Language Models (LLM's), om deze tests voor ons te schrijven. Denk aan een LLM als een superintelligente robot die bijna elk kookboek ter wereld heeft gelezen en direct nieuwe recepten kan schrijven.

Maar er is een addertje onder het gras. Deze AI-chefs zijn geweldig in het schrijven van het verhaal van de smaaktest, maar ze vergeten vaak de keukenregels. Ze kunnen vergeten de juiste ingrediënten te pakken (imports), gebruiken het verkeerde type pan (frameworks), of proberen te koken zonder het fornuis aan te zetten (ontbrekende setup). In de echte wereld is het waardeloos als een test niet compileert — wat betekent dat hij niet eens kan starten omdat er kleine fouten zijn — ongeacht hoe slim de logica ook is. Dit artikel onderzoekt waarom AI-gegenereerde tests vaak falen in rommelige, echte keukens en stelt een nieuwe manier voor om de AI te laten slagen.

Het Probleem: De AI-Chef die de Pan Vergeet

De auteurs van dit artikel, een team van Tianjin University en Huawei Cloud, merkten iets frustrerends op tijdens hun werk met grote industriële softwareprojecten. Ze probeerden de nieuwste AI-tools te gebruiken om automatisch unit tests te schrijven, en hoewel de AI slimme testideeën kon genereren, waren de resultaten in de praktijk vaak een ramp.

Stel je voor dat je een robot vraagt om een Lego-kasteel te bouwen. De robot kan een briljant ontwerp maken voor de torens en vlaggen, maar als hij vergeet de basisplaat toe te voegen of probeert een stukje uit een andere set te gebruiken dat niet past, stort het hele bouwwerk in. In softwaretermen faalde de AI vaak om de tests te "compileren". Dit gebeurde omdat de AI vaak niet wist welke bibliotheken, andere bestanden en specifieke frameworks nodig waren, omdat de AI alleen naar het ene stukje code keek waarvoor het gevraagd werd om een test te schrijven.

De onderzoekers vonden drie hoofdoorzaken voor het falen van de AI:

1. Context Mismatch: De AI raadde de regels van de keuken (zoals welk testframework gebruikt moest worden) in plaats van dat dit expliciet werd verteld. De AI raadde de verkeerde ingrediënten, wat leidde tot directe fouten.
2. Fragile Scaffolding: De AI probeerde de volledige teststructuur vanaf nul op te bouwen, inclusief de setup en imports. Het was alsof je een robot vroeg om zowel de basisplaat als het kasteel tegelijk te bouwen; de robot kreeg de basisplaat vaak fout, waardoor het hele kasteel instortte.
3. Costly Repairs: Wanneer de test faalde, was de gebruikelijke oplossing om de AI opnieuw te vragen het te proberen, en weer, en weer. Dit was also als de robot tien keer terug naar de tekentafel sturen om een missend schroefje te repareren. Het kostte veel tijd, verbruikte veel computerkracht (tokens) en vaak maakte de robot simpelweg dezelfde fout opnieuw.

De Oplossing: CATGen, de Slimme Keukenassistent

Om dit op te lossen, bouwde het team een nieuwe workflow genaamd CATGen. In plaats van de AI alles te laten raden, besloten ze te handelen als een strikte maar behulpzame keukenmanager die de werkplek perfect klaarzet voordat de chef begint met koken.

Hun aanpak bestaat uit vier hoofdstappen, die ze een "context-bewuste workflow" noemen:

1. Het Verzamelen van de Context: Voordat de AI ook maar één regel code schrijft, scant CATGen het hele project om de "ingrediënten" te vinden die nodig zijn. Het kijkt naar de build-bestanden om te zien welke testframeworks (zoals JUnit) en mocking-bibliotheken (zoals Mockito) worden gebruikt. Het controleert ook welke andere bestanden de code aanroept. Dit zorgt ervoor dat de AI precies weet welke tools beschikbaar zijn.
2. Het Bouwen van het Skelet: In plaats van de AI het hele testclass vanaf nul te laten bouwen, bouwt CATGen eerst een "skelet". Denk hierbij aan het vooraf assembleren van de Lego-basisplaat en het frame van het kasteel. Het gebruikt strikte regels om ervoor te zorgen dat de imports, klassenamen en setup-methoden 100% correct zijn. De AI wordt vervolgens alleen gevraagd om het "vlees" van de test in te vullen — de eigenlijke logica — binnen deze vooraf gebouwde, veilige structuur.
3. Het Invullen van de Gaten: De AI schrijft nu de testmethoden, maar omdat deze binnen een perfect skelet werkt, is de kans op structurele fouten veel kleiner. De focus ligt puur op de logica van de test.
4. Het Veiligheidsnet (Statische Analyse): Als de AI nog steeds een kleine fout maakt (zoals een ontbrekende puntkomma of een verkeerde variabelenaam), vraagt CATGen niet de AI om het opnieuw te proberen, maar gebruikt het een "statische analyse"-tool. Dit is als een spellingscontrole voor code die veelvoorkomende fouten direct herstelt op basis van de projectregels. Het is snel, deterministisch en verspilt geen tijd aan het opnieuw laten raden door de AI.

De Resultaten: Sneller, Slimmer en Werkelijk Functionerend

Het team heeft CATGen getest op echte industriële projecten (die zeer complex zijn) en ook op een beroemde open-source benchmark genaamd Defects4J. Ze vergeleken het met zes andere topmethoden, inclus van traditionele zoekgebaseerde tools en andere AI-benaderingen.

De resultaten waren indrukwekkend. In de industriële setting bereikte CATGen een compilatiesuccespercentage van 91,83%. Dit betekent dat van de 100 gegenereerde tests er meer dan 91 direct werkten. Ter vergelijking: de op één na beste AI-methode haalde slechts ongeveer 67%, en de traditionele tool (EvoSuite) haalde 75,80%.

Maar het ging niet alleen om het werken; het ging ook om de kwaliteit. CATGen dekte meer regels code (70,10% line coverage) en meer logische vertakkingen (63,92% branch coverage) dan de andere methoden. Misschien wel het belangrijkste: het was ongelooflijk efficiënt. Terwijl andere methoden duizenden seconden en miljoenen "tokens" (de munteenheid van AI-berekening) nodig hadden om tests te genereren en te repareren, voltooide CATGen de hele klus in slechts 1.836 seconden en gebruikte het slechts 203.000 tokens. Dit is een enorme reductie in tijd en kosten — ongeveer 50% tot 80% minder dan de andere methoden.

De onderzoekers voerden ook een "ablatie-studie" uit, wat vergelijkbaar is met het uit elkaar halen van een machine om te zien welk onderdeel wat doet. Ze ontdekten dat als ze de "skelet"-stap zouden verwijderen, het succespercentage aanzienlijk zou dalen. Als ze de "statische analyse"-reparatiestap zouden verwijderen, zou het succespercentage zelfs nog harder crashen. Dit bewees dat elk onderdeel van hun nieuwe systeem essentieel was.

De Conclusie

De grote les van dit artikel is dat het laten werken van AI in de echte wereld niet alleen gaat over het schrijven van een betere "prompt" (de instructies die je aan de AI geeft). Het gaat over het bouwen van een beter systeem rondom de AI. Door de AI de juiste context te geven, een solide fundament te bieden om op te werken en snelle, niet-AI-tools te gebruiken om kleine fouten te herstellen, kunnen we AI-gegenereerde tests daadwerkelijk bruikbaar maken voor ontwikkelaars.

De auteurs suggereren dat als AI echt nuttig wil zijn in software engineering, we moeten stoppen met het behandelen van AI als een toverstaf die alles uit zichzelf oplost. In plaats daarvan moeten we het behandelen als een krachtig onderdeel van een groter, goed ontworpen systeem. Zoals zij stellen: betrouwbare testgeneratie hangt minder af van "prompt engineering" alleen en meer van "systematische engineering ondersteuning". Uiteindelijk laat CATGen zien dat wanneer je de AI-chef een passende keuken en een duidelijk recept geeft, hij echt goede tests kan bereiden.