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

Questo studio presenta la prima valutazione empirica su larga scala della generazione di test unitari da parte di modelli linguistici (LLM) a livello di classe, dimostrando che sebbene le tecniche di prompting basate sul ragionamento migliorino l'affidabilità e la leggibilità rispetto ai metodi tradizionali, le elevate percentuali di fallimenti di compilazione e i difetti di manutenibilità rendono necessari approcci ibridi per risultati pronti alla produzione.

L'essenziale

Ecco una spiegazione semplice e creativa di questo studio, pensata per chiunque, anche senza conoscenze tecniche di programmazione.

🧪 Il Grande Esperimento: Chi è il Migliore "Autore di Testi" per il Codice?

Immagina di dover costruire una casa (il software). Per essere sicuri che non crolli, devi fare dei test: aprire le finestre, tirare i rubinetti, saltare sui pavimenti. Nel mondo del software, questi si chiamano test unitari.

Fare questi test a mano è noioso e richiede tempo. Per anni, gli informatici hanno usato dei "robot matematici" (chiamati EvoSuite) che provano a rompere la casa in mille modi diversi. Funzionano bene, ma i loro rapporti sono scritti in una lingua strana, piena di errori di ortografia e difficili da capire per un umano.

Ora, sono arrivati i LLM (i grandi modelli di intelligenza artificiale come ChatGPT). Sono come scrittori molto colti che possono scrivere codice e spiegazioni in un italiano (o inglese) perfetto. Ma c'è un problema: a volte questi scrittori sono così sicuri di sé che inventano cose che non esistono (le "allucinazioni").

Questo studio è stato un grande torneo per vedere chi vince: il robot matematico o lo scrittore AI? E soprattutto: come possiamo insegnare allo scrittore a non allucinare?

---

🎭 I Personaggi del Torneo

1. EvoSuite (Il Robot Matematico):

   • Chi è: Un vecchio saggio che non sbaglia mai la grammatica.
   • Punto di forza: È ossessionato dal coprire ogni angolo della casa. Se c'è un muro, lo tocca.
   • Debolezza: I suoi rapporti sono incomprensibili. Sembra scritto da un alieno.

2. I Modelli AI (GPT-3.5, GPT-4, Mistral, Mixtral):

   • Chi sono: Quattro scrittori diversi. Alcuni sono più grandi e intelligenti (GPT-4), altri più veloci ed economici (Mistral).
   • Punto di forza: Scrivono codice che sembra fatto da umani. È ordinato, ha nomi sensati ed è facile da leggere.
   • Debolezza: Tendono a inventare dettagli. Possono dire "Ho aperto la finestra" quando in realtà la finestra non esiste nel codice.

3. I "Coach" (Le Tecniche di Prompting):

   • Per aiutare gli scrittori AI, i ricercatori hanno usato 5 metodi diversi (come dare istruzioni diverse a un assistente):
     • ZSL (Zero-Shot): "Ehi, scrivi un test." (Nessun aiuto).
     • FSL (Few-Shot): "Ecco un esempio, ora tu fai lo stesso." (Con un esempio).
     • CoT (Chain-of-Thought): "Pensa passo dopo passo prima di scrivere." (Ragionamento a catena).
     • ToT (Tree-of-Thought): "Immagina tre esperti che discutono e scelgono la soluzione migliore." (Albero di pensiero).
     • GToT (Guided Tree-of-Thought): La tecnica vincente! È come avere tre esperti senior che lavorano insieme, controllandosi a vicenda e correggendo gli errori prima di consegnare il lavoro.

---

🏆 Cosa è Emerso dal Torneo?

Ecco i risultati principali, spiegati con metafore:

1. La "Sindrome dell'Allucinazione" (Il problema più grande)

Gli scrittori AI sono bravissimi a scrivere, ma inventano cose.

• L'analogia: Immagina che uno scrittore ti dica: "Ho usato il martello rosso per inchiodare la porta". Ma nel tuo garage non c'è nessun martello rosso, e la porta non ha bisogno di chiodi.
• Il risultato: Il 86% dei testi scritti dall'AI non funziona subito perché citano strumenti o regole che non esistono nel progetto reale. È come se un cuoco scrivesse una ricetta usando ingredienti che non hai in cucina.

2. Chi scrive meglio? (Leggibilità)

• EvoSuite (Il Robot): Scrive codice che funziona al 100%, ma è illeggibile. È come un manuale di istruzioni scritto in codice binario: perfetto per la macchina, inutile per te.
• L'AI (Lo Scrittore): Scrive codice che sembra fatto da un umano. È pulito, ordinato e facile da capire.
• Vincitore: Se vuoi qualcosa che un umano possa leggere e mantenere, l'AI vince di gran lunga.

3. Chi copre più terreno? (Copertura)

• EvoSuite: Esplora ogni angolo della casa. Se c'è un buco nel muro, lo trova. Copre il 94% del codice.
• L'AI: Si concentra sugli angoli più importanti e ovvi. Copre circa il 75% del codice.
• Vincitore: Il Robot è ancora più bravo a trovare buchi nascosti, ma lo scrittore AI è più veloce e comprensibile.

4. Il Trucco del "Coach" (Prompt Engineering)

C'era un grande dubbio: "Se chiedo all'AI di ragionare prima di scrivere, fa meno errori?"

• Risultato: Sì!
• Usare la tecnica GToT (i tre esperti che ragionano insieme) ha ridotto drasticamente gli errori. È come se invece di dare un compito a un bambino, lo dessi a un team di professori che si controllano a vicenda.
• Tuttavia, anche con i professori, l'AI continua a inventare qualche ingrediente che non esiste (le allucinazioni).

5. Gli "Odori" del Codice (Test Smells)

In informatica, un "test smell" è come un cattivo odore in cucina: non significa che il cibo è avvelenato, ma che c'è qualcosa che non va e che potrebbe rovinare il pasto in futuro.

• L'AI: Scrive testi puliti, ma spesso usa numeri magici (es. "metti 15" senza dire perché 15) o fa troppe affermazioni confuse.
• Il Robot: Fa testi pieni di "cattivi odori" strutturali, ma almeno sono coerenti.

---

💡 La Conclusione Semplice

Immagina di dover scrivere un libro di istruzioni per una nuova macchina.

• EvoSuite è un ingegnere che scrive un manuale tecnico perfetto, ma in una lingua che solo lui capisce. È utile per la macchina, ma tu non ci capisci nulla.
• L'AI è un giornalista brillante che scrive un manuale bellissimo, chiaro e divertente. Ma a volte, per sbaglio, scrive che la macchina ha un motore a vapore quando in realtà è elettrica.

La soluzione migliore?
Non scegliere uno dei due. Usali insieme.
Lascia che l'AI (guidata dal "Coach" GToT) scriva la bozza del manuale, rendendolo chiaro e leggibile per gli umani. Poi, lascia che il Robot (EvoSuite) controlli il lavoro, corregga gli errori di fattibilità e assicuri che ogni dettaglio sia tecnicamente corretto.

In sintesi: L'Intelligenza Artificiale è un ottimo assistente per scrivere test di qualità, ma non è ancora pronta per lavorare da sola. Ha bisogno di un supervisore umano o di un robot di controllo per evitare di inventare cose che non esistono.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del documento di ricerca "Prompt Engineering in LLMs for Automated Unit Test Generation: A Large-Scale Study", redatto in italiano.

1. Il Problema

La generazione automatica di test unitari è fondamentale per l'affidabilità del software, ma la creazione manuale è spesso trascurata a causa dei tempi lunghi. Gli approcci tradizionali basati sulla ricerca (SBST - Search-Based Software Testing), come EvoSuite, ottimizzano la copertura del codice ma producono test scarsamente leggibili, difficili da mantenere e talvolta inefficaci nel rilevare difetti.
I Modelli Linguistici di Grande Dimensione (LLM) offrono una promessa di generare test più leggibili e simili a quelli umani. Tuttavia, esistono lacune significative nella ricerca attuale:

• Mancanza di valutazioni su larga scala a livello di classe (la maggior parte degli studi si ferma al livello di metodo).
• Valutazione insufficiente delle strategie di prompt engineering avanzate (oltre al semplice Zero-Shot).
• Scarsa analisi della robustezza strutturale, della compilabilità e dei "test smell" (cattive pratiche di test) in scenari reali.
• Preoccupazioni riguardo alla "fuga di dati" (data leakage), dove i modelli potrebbero aver memorizzato i test di addestramento invece di generarli realmente.

2. Metodologia

Lo studio presenta una valutazione empirica su larga scala che coinvolge 216.300 casi di test generati per 690 classi Java.

• Dataset Utilizzati:
  • Defects4J: Software reale con bug noti (focus su scenari di correzione).
  • SF110: Programmi Java con test esistenti (focus su complessità architetturale).
  • CMD (Custom Mini Dataset): Un dataset curato con progetti rilasciati dopo maggio 2023 per mitigare il rischio di data leakage (i modelli non dovrebbero aver visto questi dati durante l'addestramento).
• Modelli LLM Valutati:
  • GPT-3.5-turbo, GPT-4 (OpenAI).
  • Mistral 7B, Mixtral 8x7B (MistralAI).
• Tecniche di Prompt Engineering:
  Sono state confrontate cinque strategie:
  1. ZSL (Zero-Shot Learning).
  2. FSL (Few-Shot Learning).
  3. CoT (Chain-of-Thought).
  4. ToT (Tree-of-Thought).
  5. GToT (Guided Tree-of-Thought): Un approccio innovativo proposto dagli autori che simula la collaborazione tra tre "tester" esperti per iterare e rifinare i test.
• Baseline:
  • EvoSuite: Lo stato dell'arte per la generazione di test basata sulla ricerca (SBST) per Java, utilizzato come riferimento per la copertura e la compilabilità.
• Metriche di Valutazione:
  • MSR & CSR: Match Success Rate e Code Extraction Success Rate per valutare la capacità di estrarre codice strutturato dal testo naturale.
  • Correttezza Sintattica e Compilabilità: Analisi degli errori di compilazione e delle allucinazioni (es. riferimenti a simboli inesistenti).
  • Leggibilità e Manutenibilità: Utilizzo di modelli di deep learning (Scalabrino et al.) e metriche di complessità (Cyclomatic/Cognitive).
  • Test Smell: Rilevamento automatico di cattive pratiche (es. Assertion Roulette, Magic Number) tramite TsDetect.
  • Copertura del Codice: Linee, istruzioni e metodi coperti (misurati con JaCoCo).

3. Contributi Chiave

1. Investigazione Sistematica del Prompt Engineering: Prima valutazione su larga scala che confronta cinque tecniche di prompting (incluso il nuovo GToT) su modelli generici per la generazione di test.
2. Analisi di Correttezza Strutturale ed Estraibilità: Introduzione di metriche (MSR/CSR) per decouplare la formattazione dalla correttezza sintattica, evidenziando quanto sia difficile estrarre test puliti dagli output degli LLM.
3. Distinzione tra Leggibilità e Manutenibilità: Dimostrazione che la leggibilità non garantisce la manutenibilità, analizzando i "test smell" e la complessità cognitiva.
4. Valutazione Multi-Modello e Multi-Dataset: Confronto tra modelli OpenAI e Mistral su dataset eterogenei, inclusa una valutazione rigorosa contro il rischio di data leakage.
5. Benchmark Pubblico: Rilascio di un pacchetto di replicazione completo con prompt, script di valutazione e risultati.

4. Risultati Principali

• Capacità di Generazione (RQ0): Gli LLM generano output quasi sempre (tassi >90%), mentre EvoSuite fallisce in alcuni casi complessi (es. 77.6% su Defects4J). Tuttavia, la mera generazione non garantisce codice valido.
• Impatto del Prompting (RQ1):
  • GToT è la strategia più efficace per garantire che l'output segua il formato richiesto (alta MSR) e sia estraibile.
  • L'uso di delimitatori espliciti (es. ###Test START###) aiuta, ma non risolve completamente l'inconsistenza degli LLM nel seguire le istruzioni di formattazione.
• Correttezza e Compilabilità (RQ2):
  • Divario Critico: Sebbene il ~90% del codice estratto sia sintatticamente corretto, solo meno del 10% compila effettivamente senza errori.
  • Cause di Fallimento: Le principali cause sono allucinazioni (riferimenti a simboli inesistenti, pacchetti mancanti, violazioni di incapsulamento).
  • Confronto con SBST: EvoSuite ha un tasso di compilazione quasi perfetto (>98%), rendendo gli LLM attualmente molto meno affidabili per l'integrazione diretta.
• Leggibilità e Manutenibilità (RQ3 & RQ4):
  • Gli LLM generano test significativamente più leggibili (+21-40%) rispetto a EvoSuite, con nomi di variabili più chiari e strutture più comprensibili.
  • Le strategie basate sul ragionamento (CoT, GToT) migliorano ulteriormente la leggibilità.
  • Tuttavia, la leggibilità non elimina i difetti strutturali: i test generati dagli LLM soffrono ancora di Magic Number Tests e Assertion Roulette.
• Copertura del Codice (RQ5):
  • EvoSuite supera costantemente gli LLM in termini di copertura (linee, istruzioni, metodi) grazie alla sua natura esplorativa.
  • Gli LLM raggiungono coperture moderate (es. ~75% su Defects4J con CoT), ma faticano su progetti complessi (SF110) e mostrano una forte dipendenza dal dataset (possibile memorizzazione su Defects4J).
• Test Smell (RQ6):
  • Gli LLM riducono alcuni smell legati alla complessità (es. General Fixture) rispetto a EvoSuite.
  • Tuttavia, il Magic Number Test è onnipresente (fino al 100%).
  • Le strategie di ragionamento (CoT, GToT) riducono drasticamente l'Assertion Roulette rispetto allo Zero-Shot o a Few-Shot.

5. Significato e Conclusioni

Lo studio conclude che gli LLM, sebbene promettenti, non sono ancora pronti per sostituire gli strumenti di generazione di test tradizionali o per essere utilizzati in modo autonomo in produzione.

• Ruolo Attuale: Gli LLM sono eccellenti come strumenti assistivi per generare scheletri di test leggibili e manutenibili, migliorando l'esperienza dello sviluppatore.
• Limiti: La fragilità nella compilazione (a causa di allucinazioni di dipendenze) e la persistenza di cattive pratiche (test smell) richiedono un intervento umano o automatizzato.
• Direzione Futura: La soluzione ottimale risiede in approcci ibridi che combinano la generazione basata su LLM (per leggibilità e struttura) con la raffinazione basata sulla ricerca (SBST) e la validazione automatica (per copertura e correttezza).
• Implicazioni per i Ricercatori: È necessario sviluppare pipeline di generazione che integrino la risoluzione delle dipendenze e la validazione iterativa, andando oltre la semplice generazione di codice grezzo.

In sintesi, il Prompt Engineering (in particolare GToT) migliora la qualità strutturale degli LLM, ma non colma il divario di affidabilità rispetto agli strumenti SBST maturi come EvoSuite.