Improving LLM-Driven Test Generation by Learning from Mocking Information

Probleemstelling

Hoewel Large Language Models (LLMs) veelbelovend zijn voor het automatisch genereren van unit-tests, missen bestaande LLM-gebaseerde benaderingen vaak specifieke context die ontwikkelaars hebben vastgelegd in bestaande test suites. Traditionele methoden genereren tests voornamelijk op basis van de code onder test (CUT) en documentatie. Ze negeren echter de rijke informatie die voortkomt uit test doubles (zoals mocks en stubs).

In moderne softwareontwikkeling gebruiken ontwikkelaars mocks om afhankelijkheden te isoleren. Deze mocks bevatten waardevolle, impliciete kennis over hoe componenten moeten worden gebruikt:

1. Welke methoden worden aangeroepen?
2. Welke argumenten worden doorgegeven?
3. Wat zijn de verwachte retourwaarden of uitzonderingen?

Zonder deze informatie kunnen LLMs realistische interacties missen, wat leidt tot tests die minder gedetailleerd zijn en minder fouten opsporen dan tests die gebaseerd zijn op bestaande ontwikkelaarspatronen.

Methodologie: MOCKMILL

De auteurs introduceren MOCKMILL, een LLM-gebaseerde techniek en tool die bestaande mocking-informatie uit een project gebruikt om nieuwe, betere tests te genereren voor de componenten die in die tests worden gemockt.

Het proces verloopt in vier fasen:

1. Projectanalyse:

   • De tool analyseert de testbestanden van een project (met name JUnit 5 en Mockito in Java).
   • Het identificeert welke componenten (CUTs) worden vervangen door test doubles en welke mocks of stubs erop zijn gedefinieerd.
   • Alleen componenten die tot het project zelf behoren (geen externe bibliotheken) worden geselecteerd als doelwit.

2. Mock Extractie (Kerninnovatie):

   • Via statische analyse (AST-parsing) worden de specifieke details van de mocking-opdrachten geëxtraheerd.
   • Dit omvat when(...).thenReturn(...) (stubbing) en verify(...) (interactiecontroles).
   • Deze data wordt gestructureerd in een JSON-formaat. Dit voorkomt dat de volledige testcode aan de LLM wordt gegeven (wat de contextwindow zou overbelasten) en focust puur op het gedrag dat moet worden nagebootst.

3. Test Generatie:

   • De LLM ontvangt een prompt met drie componenten:
     1. De instructies voor het genereren van tests (gericht op mutatie-adequaatheid).
     2. De volledige broncode van de doelcomponent (CUT).
     3. De geëxtraheerde mocking-data (stubbing en verificatiepatronen).
   • De prompt instrueert de LLM om echte objecten te instantiëren (in plaats van ze te mocken in de nieuwe test) en te testen op de patronen die uit de bestaande mocks zijn afgeleid.
   • Er wordt gebruik gemaakt van few-shot prompting met domein-neutrale voorbeelden.

4. Post-Generatie Reparatie:

   • Een iteratieve lus compileert en voert de gegenereerde tests uit.
   • Bij compilatiefouten of runtime-fouten worden de foutmeldingen teruggevoerd naar de LLM met instructies om de test te repareren.
   • Dit proces herhaalt zich tot de test succesvol compileert en draait of een limiet is bereikt.

Belangrijkste Bijdragen

• MOCKMILL Tool: De eerste tool die expliciet bestaande mocking-informatie gebruikt als contextuele gids voor LLM-gestuurde testgeneratie.
• Nieuwe Benadering: In plaats van alleen te vertrouwen op broncode of documentatie, leert het systeem van de "intentie" die ontwikkelaars al hebben vastgelegd in hun testdoubles.
• Open Source: De code en experimentele data zijn beschikbaar gesteld voor replicatie.

Resultaten

De evaluatie werd uitgevoerd op 10 klassen uit 6 open-source Java-projecten, met gebruik van vier LLMs (GPT-4O MINI, GPT-5 MINI, GPT-5, en Claude Sonnet 4.5).

• Effectiviteit (RQ1):
  • MOCKMILL produceert tests met hoge compilatie- en uitvoerbaarheid (tot 100% na reparatie).
  • De gegenereerde tests behalen hoge mutatiescores (foutopsporing) en lijndekking. GPT-5 MINI bleek de beste balans te bieden tussen kosten en prestaties.
• Complementariteit (RQ2):
  • Tests van MOCKMILL vullen bestaande tests en baseline-methoden (zoals RANDOOP en een LLM zonder mock-data) aan.
  • Unieke Mutaties: MOCKMILL doodde unieke mutaties die door andere methoden werden gemist (bijv. 24,56% unieke mutaties gedood voor de CustomerApplicationService klasse, vergeleken met 1,75% voor de baseline).
  • Unieke Dekking: Hoewel de extra lijndekking beperkt was (vaak <3%), toonde het aan dat MOCKMILL specifieke codepaden bereikte die anders onbedekt bleven.
  • Developer-tests werden vaak overtroffen door LLM-generatie, en mocking-informatie verbeterde deze prestatie verder.
• Kosten (RQ3):
  • Het gebruik van mocking-informatie verhoogt de kosten met slechts 5-15% ten opzichte van een standaard LLM-benadering, vanwege de iets langere prompt.
  • Dit is een zeer gunstige trade-off gezien de toename in foutopsporing.

Significantie en Conclusie

Het artikel biedt bewijs dat het benutten van bestaande mocking-informatie een effectieve en kostenefficiënte manier is om LLM-gestuurde testgeneratie te verbeteren.

• Contextuele Gids: Mocking-data fungeert als een "geheugen" voor de LLM over hoe een component in de praktijk wordt gebruikt, wat leidt tot realistischere tests.
• Synergie: De methode vervangt geen bestaande tools, maar vult ze aan. Een holistisch testframework zou zowel mock-informed als non-mock-informed prompts moeten combineren.
• Toekomstperspectief: De auteurs suggereren dat toekomstig onderzoek zich moet richten op het automatiseren van het extraheren van projectspecifieke voorbeelden en het uitbreiden van de tool naar andere programmeertalen (zoals Python en JavaScript) en frameworks.

Kortom, MOCKMILL demonstreert dat het "leren van de ontwikkelaars" via hun bestaande testdoubles de kwaliteit en dekking van automatisch gegenereerde tests aanzienlijk kan verhogen tegen een minimale extra kostprijs.