Large-scale, Independent and Comprehensive study of the power of LLMs for test case generation

Deze grootschalige studie concludeert dat hoewel reasoning-based prompting (zoals GToT) de betrouwbaarheid en leesbaarheid van door LLM's gegenereerde unit-tests verbetert, de hoge rate aan compilatiefouten en testgeurproblemen de noodzaak onderstreept voor hybride benaderingen die LLM-generatie combineren met automatische validatie.

De kern

Stel je voor dat je een enorme fabriek hebt waar software wordt gebouwd. Om te zorgen dat alles goed werkt, moeten de ingenieurs constant testen of de machines niet vastlopen. Dit noemen we unit testing.

Vroeger deden mensen dit handmatig: het was saai, duur en veel mensen vergeten het. Later kwamen er slimme robots (zoals EvoSuite) die automatisch tests schreven. Die robots waren heel goed in het vinden van alles wat kapot kon gaan (ze hadden een hoge "dekking"), maar hun tests waren vaak onleesbaar, vol met rare namen en leken meer op een rommelige schets dan op een duidelijk verhaal.

Nu hebben we LLMs (zoals ChatGPT) die kunnen schrijven alsof ze mensen zijn. De vraag in dit onderzoek is: Kunnen deze AI's betere tests schrijven dan de oude robots? En vooral: Hoe moeten we ze vragen (prompten) om het beste resultaat te krijgen?

Hier is wat de onderzoekers hebben ontdekt, vertaald naar alledaagse taal:

1. De "Vraagstelling" is cruciaal (Prompt Engineering)

Stel je voor dat je een kok (de AI) vraagt om een taart te bakken.

• Zonder instructies (Zero-Shot): "Maak een taart." De AI maakt er misschien eentje, maar hij vergeet deeg, gebruikt een plastic kom en de taart is plat.
• Met voorbeelden (Few-Shot): "Hier is een taart die ik eerder maakte. Maak er eentje zoals deze." Dit helpt soms, maar de AI kopieert soms gewoon de fouten uit het voorbeeld.
• Met redenering (Chain-of-Thought): "Denk eerst na: wat heb ik nodig? Meel, eieren, suiker. Schrijf dan het recept op." Dit werkt veel beter.
• De "Super-Kok" aanpak (Guided Tree-of-Thought): Dit is de beste methode die ze hebben getest. Stel je voor dat je drie experts in de keuken zet. Ze bespreken samen het recept, één zegt "nee, dat werkt niet", een ander zegt "probeer dit", en samen komen ze tot het perfecte plan voordat ze beginnen met bakken.

Conclusie: De AI's schrijven veel betere tests als je ze dwingt om eerst na te denken en samen te werken (de "Super-Kok" methode), in plaats van ze zomaar een opdracht te geven.

2. De AI's zijn creatief, maar ook hallucinerend

De AI's zijn fantastisch in het schrijven van tests die lezen als menselijk werk. Ze gebruiken mooie namen, goede zinnen en het ziet er netjes uit. De oude robot (EvoSuite) schreef tests die leken op een computerfoutmelding.

MAAR: De AI's hebben een groot probleem: ze hallucineren.
Stel je voor dat de AI een test schrijft voor een koffiezetapparaat. Hij schrijft: "Druk op de knop 'KoffieDruk'." Maar die knop bestaat niet in het echte apparaat! De AI heeft de knop verzonnen omdat het dacht dat het logisch was.

• Het gevolg: Als je de test probeert te draaien, crasht hij direct. In dit onderzoek faalden tot 86% van de AI-tests bij het compileren (het "opstarten") omdat ze op dingen verwezen die niet bestonden.
• De oude robot (EvoSuite) maakt geen hallucinaties; hij gebruikt alleen wat hij zeker weet dat er is. Daarom werkt zijn code bijna altijd direct, ook al is het lelijk.

3. Dekking: Kwaliteit vs. Kwantiteit

De oude robot (EvoSuite) is als een stofzuiger: hij zuigt elke hoek en kier schoon. Hij vindt bijna alle fouten (hoge dekking), maar laat een puinhoop achter.
De AI is als een kunstenaar: hij maakt een prachtig schilderij van de test, maar hij mist soms de hoekjes waar de stof zit.

• De AI's halen ongeveer 60-80% dekking (afhankelijk van hoe goed je vraagt), terwijl de robot 94% haalt.
• De AI's zijn dus nog niet slim genoeg om alles te vinden wat kapot kan gaan, maar ze schrijven wel tests die mensen kunnen begrijpen.

4. De "Test Geur" (Test Smells)

In de softwarewereld hebben tests soms "geurtjes" die aangeven dat ze slecht zijn gebouwd.

• Magische Getallen: De AI schrijft vaak: "Controleer of het getal 42 terugkomt." Waarom 42? Niemand weet het. Dat is een "Magisch Getal". Dit maakt het moeilijk om de test later aan te passen.
• Roulette van Asserties: De AI schrijft 10 keer "Controleer of X klopt", zonder te zeggen waarom. Als er één fout is, weet je niet welke.
• De AI's maken minder van deze "geurtjes" dan de oude robot, maar ze maken ze nog steeds veel te vaak.

Het Grote Advies: De Hybrid Oplossing

De onderzoekers concluderen dat we de AI's niet als vervanging moeten zien, maar als assistenten.

• De AI is de schrijver: Hij maakt de tests leesbaar, mooi en begrijpelijk voor mensen.
• De Oude Robot (EvoSuite) is de controleur: Hij zorgt dat er geen enkele hoekje over het hoofd wordt gezien en dat de code technisch klopt.

De beste aanpak: Laat de AI de tests schrijven (met de "Super-Kok" methode), en laat daarna de oude robot of een menselijke controleur de "hallucinaties" (de verzonnen knoppen) eruit halen en de dekking controleren.

Kort samengevat: AI's kunnen prachtige tests schrijven die mensen kunnen lezen, maar ze dromen soms dingen in die niet bestaan. We moeten ze dus slim aansturen en altijd een tweede paar ogen (of een oude robot) erover laten waken voordat we ze gebruiken in de echte wereld.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het artikel "Prompt Engineering in LLMs for Automated Unit Test Generation: A Large-Scale Study", vertaald en samengevat in het Nederlands.

Probleemstelling

Unit testen is essentieel voor softwarebetrouwbaarheid, maar het handmatig schrijven van tests is tijdrovend en wordt vaak verwaarloosd. Traditionele methoden voor geautomatiseerde testgeneratie, zoals Search-Based Software Testing (SBST) met tools als EvoSuite, genereren weliswaar hoge code-coverage, maar de gegenereerde tests zijn vaak slecht leesbaar, moeilijk te onderhouden en bevatten onintuïtieve namen.

Hoewel Large Language Models (LLMs) beloftevol lijken voor het genereren van leesbare en menselijke tests, ontbreekt er tot nu toe een uitgebreide empirische evaluatie. Bestaande onderzoek mist een systematische analyse van:

1. De impact van geavanceerde prompt-engineering-technieken (zoals Chain-of-Thought) op testkwaliteit.
2. De structurele correctheid en bruikbaarheid (extractability) van de gegenereerde code.
3. De prestaties in real-world scenario's tegenover gevestigde SBST-tools, met name op het gebied van compilatie, hallucinaties en testgeur (test smells).

Methodologie

De auteurs hebben een grootschalig empirisch onderzoek uitgevoerd om LLM-generatie van unit-tests te evalueren op class-niveau (in plaats van alleen op methodeniveau), wat beter aansluit bij realistische werkstromen.

• Modellen: Vier state-of-the-art instructie-modellen werden getest: GPT-3.5-turbo, GPT-4, Mistral 7B en Mixtral 8x7B.
• Prompt-technieken: Vijf strategieën werden vergeleken:
  • Zero-Shot Learning (ZSL)
  • Few-Shot Learning (FSL)
  • Chain-of-Thought (CoT)
  • Tree-of-Thought (ToT)
  • Guided Tree-of-Thought (GToT): Een nieuwe, door de auteurs ontwikkelde aanpak waarbij drie "experts" collaboratief testen genereren en iteratief verbeteren.
• Datasets: Drie diverse datasets werden gebruikt om generaliseerbaarheid te waarborgen:
  • Defects4J: Realistische buggy software.
  • SF110: Een benchmark met bestaande Java-tests.
  • CMD (Custom Mini Dataset): Een dataset van projecten die na mei 2023 zijn gepubliceerd, om training-data-lekkage (data leakage) te minimaliseren.
• Benchmarks: De resultaten werden vergeleken met EvoSuite, de de facto standaard voor SBST in Java.
• Evaluatiemetrics:
  • MSR & CSR: Match Success Rate en Code Extraction Success Rate om te meten of code correct uit de LLM-antwoorden kan worden geëxtraheerd.
  • Syntactische correctheid & Compilatie: Of de code compileert zonder fouten.
  • Readability & Maintainability: Geanalyseerd via een deep learning-model (Scalabrino et al.) en complexeheidsmetrieken.
  • Code Coverage: Lijn-, instructie- en methodedekking (gemeten met JaCoCo).
  • Test Smells: Detectie van slechte praktijken (bijv. "Magic Numbers", "Assertion Roulette") met TsDetect.

Belangrijkste Bijdragen

1. Systematisch Onderzoek naar Prompt Engineering: Het is de eerste studie die vijf gestructureerde prompt-technieken systematisch vergelijkt op class-niveau. Het weerlegt de claim dat redenering gebaseerde prompts (zoals CoT) weinig impact hebben op testgeneratie.
2. Structuur en Extractie-analyse: De studie introduceert een rigoureuze analyse van hoe goed LLM-outputs als standaard JUnit-testbestanden kunnen worden gebruikt, met een focus op het scheiden van code van natuurlijke taal.
3. Grootschalige Vergelijking: Een evaluatie van 216.300 gegenereerde testcases over 690 Java-classes, wat een veel bredere scope biedt dan eerdere methoden-gewijde studies.
4. Open Benchmark: De auteurs hebben een volledig replicatiepakket beschikbaar gesteld met prompts, scripts en resultaten.

Kernresultaten

• Generatiecapaciteit (RQ0): LLMs genereren bijna altijd een output (90%+), terwijl EvoSuite soms faalt om tests te genereren voor bepaalde klassen (77,6% succes op Defects4J). Echter, LLMs genereren vaak code die niet direct bruikbaar is.
• Format en Extractie (RQ1): GToT (Guided Tree-of-Thought) presteert het beste in het volgen van instructies en het produceren van gestructureerde code die makkelijk te extraheren is. Few-Shot Learning (FSL) presteerde verrassend slecht in structuur.
• Syntaxis en Compilatie (RQ2):
  • Hoewel ~90% van de LLM-code syntactisch correct is, is de compilatiesuccesrate extreem laag (<10%).
  • De belangrijkste oorzaak is hallucinatie: niet-bestaande symbolen ("Cannot Find Symbol"), ontbrekende packages en verkeerde API-aanroepen.
  • EvoSuite compilarieert bijna 100% van zijn output (behalve ~1,9% op Defects4J), wat aantoont dat LLMs nog een grote achterstand hebben in robuustheid.
• Leesbaarheid en Onderhoudbaarheid (RQ3 & RQ4):
  • LLM-genereren tests zijn beduidend leesbaarder dan EvoSuite-tests (21-40% hogere leesbaarheidsscores).
  • Redenering gebaseerde prompts (CoT, GToT) verbeteren de leesbaarheid en structuur aanzienlijk.
  • Echter, leesbaarheid garandeert geen onderhoudbaarheid: veel tests bevatten nog steeds "test smells".
• Code Coverage (RQ5):
  • EvoSuite overtreft LLMs aanzienlijk in code coverage (94%+ mediane lijn-coverage vs. ~40-75% voor LLMs).
  • LLMs worstelen met complexe projecten (SF110), maar doen het beter op Defects4J (mogelijk door training-data lekkage).
  • Redenering gebaseerde prompts verbeteren de coverage van LLMs, maar sluiten de kloof met SBST niet volledig.
• Test Smells (RQ6):
  • Magic Number Tests komen overal voor (85-100%), ongeacht de prompt of het model.
  • Assertion Roulette (onduidelijke asserties) wordt sterk verminderd door GToT en CoT (tot 6,4% bij GPT-3.5 CoT, vergeleken met 79% bij FSL).
  • EvoSuite vertoont juist veel "Lazy Test" en "Exception Handling" smells, terwijl LLMs vaak "Empty Tests" genereren.

Betekenis en Conclusie

De studie concludeert dat LLMs uitstekende assistentie-tools zijn voor het genereren van leesbare en onderhoudbare test-skeletten, vooral wanneer redenering gebaseerde prompts (zoals GToT) worden gebruikt. Ze overtreffen traditionele tools in menselijke kwaliteit (leesbaarheid, naamgeving).

Echter, LLMs zijn nog niet klaar om volledig autonome testgeneratie te vervangen vanwege:

1. Hoge compilatiefouten door hallucinaties (ontbrekende imports, verkeerde symbolen).
2. Lage code coverage vergeleken met SBST.
3. Persistente testgeur (vooral Magic Numbers).

Aanbeveling: De toekomst ligt in hybride benaderingen. Een ideale pipeline zou SBST (zoals EvoSuite) gebruiken voor maximale dekking en robuustheid, gecombineerd met LLMs voor het refactoren van de code naar een leesbare, mensvriendelijke vorm, ondersteund door automatische validatie en dependency-resolutie. Prompt engineering is cruciaal, maar op zichzelf niet voldoende om de betrouwbaarheid van testgeneratie te garanderen.