Automated Test Suite Enhancement Using Large Language Models with Few-shot Prompting

Titolo: Miglioramento delle Suite di Test Automatizzate tramite Grandi Modelli Linguistici con Prompting Few-Shot

1. Il Problema

La scrittura manuale dei test unitari è un processo laborioso e costoso, mentre gli approcci tradizionali automatizzati (come il Search-Based Software Testing - SBST) spesso generano test privi di leggibilità e naturalezza, rendendoli difficili da mantenere. Sebbene i Grandi Modelli Linguistici (LLM) abbiano mostrato risultati promettenti nella generazione di codice, la loro capacità di generare test unitari di alta qualità rimane una sfida a causa di problemi come l'illucinazione (codice sintatticamente valido ma logicamente errato) e la non deterministica.
Il gap di ricerca identificato riguarda la scarsa esplorazione del few-shot prompting (apprendimento da esempi) per la generazione di test. In particolare, non è chiaro come la fonte degli esempi (scritti da umani, generati da SBST o da altri LLM) e le tecniche di selezione di questi esempi influenzino la qualità dei test generati e il loro contributo al miglioramento delle suite di test esistenti in ambienti ibridi (umano-AI).

2. Metodologia

Gli autori hanno condotto un'analisi empirica utilizzando il modello GPT-4o (integrato in GitHub Copilot) su due dataset benchmark: HumanEval (esercizi di codifica isolati) e ClassEval (test che richiedono riferimenti a livello di classe e cross-file).

• Setup Sperimentale:

  • Fonti degli Esempi (Few-Shot): Sono stati creati tre tipi di dataset di esempio per il prompting:
    1. Test scritti da umani (convertiti in pytest).
    2. Test generati da SBST (usando lo strumento Pynguin).
    3. Test generati da LLM (usando GPT-4o con prompting zero-shot).
  • Tecniche di Selezione: Hanno confrontato la selezione casuale (da tutta la suite o solo dalla classe sotto test) con tecniche di retrieval basate sulla similarità (TF-IDF e similarità del coseno) che considerano:
    • Similarità della definizione del problema (testo).
    • Similarità del codice sorgente.
    • Similarità combinata (Codice + Commenti di definizione del problema).
  • Pipeline di Valutazione:
    1. Prompting: Costruzione di prompt con 5 esempi (numero ottimizzato in esperimenti preliminari).
    2. Validazione e Riparazione: I test generati sono stati sottoposti a un processo di riparazione basato su regole (es. aggiunta di import mancanti, rimozione di argomenti self errati, correzione di errori di sintassi) per gestire i fallimenti comuni.
    3. Ottimizzazione della Suite: I nuovi test sono stati integrati nella suite esistente solo se miglioravano la copertura (linee e rami), eliminando i ridondanti.

• Metriche di Valutazione:

  • Correttezza Funzionale: Correttezza sintattica, compilabilità ed esecuzione (pass/fail).
  • Copertura: Copertura delle righe (Line Coverage) e dei rami (Branch Coverage).
  • Qualità del Codice: Complessità ciclomatica, complessità cognitiva, presenza di "test smells" (anti-pattern) e debito tecnico.

3. Contributi Chiave

• Analisi Comparativa delle Fonti: Il primo studio a confrontare sistematicamente l'impatto di esempi provenienti da umani, SBST e LLM sulla generazione di test tramite few-shot prompting.
• Valutazione della Selezione degli Esempi: Valutazione empirica di come le tecniche di retrieval (basate su similarità di testo e codice) influenzino la qualità rispetto alla selezione casuale.
• Focus sul Miglioramento della Suite Esistente: Spostamento del focus dalla generazione di suite da zero al miglioramento (enhancement) di suite ibride esistenti, un scenario più realistico per lo sviluppo software.
• Pipeline di Riparazione: Implementazione e validazione di una pipeline di riparazione basata su regole che dimostra come molti errori di esecuzione siano minori e risolvibili automaticamente.

4. Risultati Principali

• Correttezza e Riparazione: Sebbene i test generati inizialmente abbiano tassi di esecuzione bassi (spesso <20% prima della riparazione), l'applicazione di regole di riparazione semplici ha portato i tassi di successo a oltre l'80% per tutte le fonti. Gli esempi SBST hanno mostrato la migliore correttezza iniziale, mentre gli esempi umani hanno portato alla migliore correttezza post-riparazione.
• Copertura:
  • Gli esempi scritti da umani hanno prodotto i test con la copertura più alta e la migliore correttezza complessiva.
  • Tuttavia, per il miglioramento delle suite esistenti (specialmente quelle con copertura iniziale bassa), gli esempi SBST hanno dimostrato di essere i più efficaci nel colmare i gap di copertura, superando talvolta gli esempi umani che partivano già da una copertura elevata.
• Selezione degli Esempi: La tecnica di selezione basata sulla similarità combinata tra definizione del problema e codice sorgente ("Problem+Code") ha costantemente prodotto i risultati migliori in termini di copertura e qualità, superando la selezione casuale.
• Qualità del Codice:
  • I test generati con esempi umani tendono ad avere una complessità cognitiva leggermente più alta (più complessi ma comprensibili).
  • Non sono state osservate differenze significative negli "test smells" o nel debito tecnico tra le diverse fonti, suggerendo che i test LLM possono essere mantenibili se guidati correttamente.
  • L'uso di esempi SBST ha talvolta portato a un aumento della complessità ciclomatica, indicando una generazione di percorsi di esecuzione più numerosi ma potenzialmente meno leggibili.

5. Significato e Implicazioni

• Per i Ricercatori: Lo studio evidenzia che la valutazione dei test generati da LLM non deve limitarsi alla correttezza e alla copertura, ma deve includere metriche di manutenibilità (complessità cognitiva, smells). Inoltre, conferma che la scelta della fonte degli esempi e la strategia di selezione sono fattori critici spesso sottovalutati.
• Per la Pratica Industriale:
  • I test generati da LLM sono più efficaci come strumenti di integrazione per suite esistenti piuttosto che come sostituti completi dei test umani.
  • L'approccio "few-shot" guidato da esempi pertinenti (selezionati tramite similarità codice/testo) permette di colmare efficacemente le lacune di copertura.
  • La necessità di infrastrutture complesse è ridotta grazie all'efficacia delle semplici riparazioni basate su regole, rendendo l'adozione di questi strumenti più accessibile.
  • Gli sviluppatori non devono necessariamente affidarsi solo a esempi umani; in contesti con copertura iniziale scarsa, esempi generati automaticamente (SBST) possono essere superiori per guidare l'LLM verso una maggiore copertura.

In conclusione, il paper dimostra che l'uso strategico del few-shot prompting, combinato con tecniche di selezione degli esempi basate sulla similarità e una pipeline di riparazione leggera, può trasformare gli LLM in strumenti potenti per il miglioramento della qualità e della copertura delle suite di test nel ciclo di sviluppo software moderno.