Riepilogo Tecnico: MocklessTester

Enunciato del Problema

Sebbene i Modelli Linguistici su Grande Scala (LLM) abbiano dimostrato potenziale per la generazione automatizzata di test, gli approcci esistenti per Java si basano principalmente su framework di mocking (ad esempio Mockito) per isolare il metodo sotto test (MUT) dalle sue dipendenze. Questa dipendenza introduce due limitazioni fondamentali:

1. Copertura Superficiale: I test con mocking esercitano il MUT in isolamento, lasciando il comportamento effettivo delle classi di dipendenza non testato.
2. Fragilità del Mock: I test diventano strettamente accoppiati a comportamenti API ipotetici, rompendosi quando le dipendenze evolvono anche se il comportamento reale rimane compatibile.

Il testing senza mocking (mockless), che istanzia ed esegue dipendenze reali, offre una soluzione ma affronta sfide significative. Generare test validi senza mocking richiede un rigoroso rispetto dei vincoli linguistici, un'istanziazione corretta degli oggetti e sequenze di chiamate API valide. Gli attuali approcci basati su LLM faticano in questo ambito a causa di due cause radice di allucinazione:

• Non Conoscere: L'LLM manca di un contesto specifico del progetto sufficiente (ad esempio, costruttori validi, metodi factory o pattern di utilizzo) per generare codice corretto.
• Non Seguire: Anche quando i vincoli sono forniti, l'LLM non riesce a rispettarli (ad esempio, violando la validità dei simboli o i protocolli di chiamata API), spesso a causa della mancanza di meccanismi di enforcement.

Metodologia: MocklessTester

Gli autori propongono MocklessTester, un approccio di generazione di test unitari senza mocking per Java che impiega un flusso di lavoro iterativo pianifica-genera-valida-correggi. Il sistema è costruito attorno a due strategie fondamentali per affrontare le cause radice identificate: Generazione Arricchita dal Contesto e Correzione con Enforcement dei Vincoli.

1. Fase di Preparazione

Prima dell'inizio della generazione dei test, MocklessTester analizza il repository target per costruire tre artefatti specifici del progetto:

• Grafo delle Proprietà del Codice (CPG): Costruito utilizzando Joern, questo grafo cattura l'uso delle dipendenze, consentendo il recupero di esempi reali di costruzione di oggetti e chiamate API tramite slicing del programma.
• ClassIndex: Un registro di tutte le classi, metodi, costruttori e importazioni visibili al progetto. Funge da verità fondamentale per la validazione dei simboli e la risoluzione dei tipi durante la riparazione.
• Modello Markoviano di Typestate: Un modello probabilistico che cattura gli ordini validi di chiamate di metodi per API con stato. Viene inizializzato da evidenze del codice sorgente e aggiornato dinamicamente in base ai risultati dei test per rilevare sequenze di chiamate illegali.

2. Ciclo Iterativo Multi-Agente

Il processo di generazione coinvolge cinque agenti: Inizializzatore, Pianificatore, Generatore, Validatore e Correttore.

• Generazione Arricchita dal Contesto: Per mitigare il "Non Conoscere", il Generatore non si basa esclusivamente sul codice sorgente della Classe Sotto Test (CUT). Invece, uno slicer del programma estrae pattern reali di istanziazione e utilizzo delle dipendenze dal codice di produzione e di test del progetto. Questi pattern vengono iniettati nel prompt per guidare l'LLM nella creazione di istanziazioni di oggetti plausibili.
• Correzione con Enforcement dei Vincoli: Per mitigare il "Non Seguire", il Correttore impiega un meccanismo di riparazione in due fasi per i test falliti:
  • Fase I (Correttore I): Genera una correzione iniziale basata sul feedback di esecuzione (errori di compilazione/runtime).
  • Fase II (Correttore II): Se la correzione iniziale viola i vincoli, viene attivata una seconda riparazione. L'LLM deve generare una correzione che soddisfi tre livelli di vincoli e fornire una giustificazione strutturata che spieghi come la correzione risolve il fallimento e aderisce alle regole:
    • Livello Simbolo: Garantisce che tutte le classi, i metodi e le importazioni esistano nel ClassIndex.
    • Livello Protocollo: Garantisce che le sequenze di chiamate API rispettino il modello Markoviano di typestate (ad esempio, inizializzare lo stato prima dell'uso).
    • Livello Iterazione: Sfrutta la Memoria delle Esperienze, che memorizza pattern di riparazione riusciti ("test oro"), ricette di correzione e anti-pattern per evitare di ripetere fallimenti noti.

Contributi Chiave

1. Prompting Arricchito dal Contesto: Gli autori identificano i pattern di utilizzo delle dipendenze come contesto critico. Propongono una strategia che potenzia l'LLM con esempi reali di istanziazione di dipendenze estratti dal progetto target, riducendo significativamente le allucinazioni causate da conoscenze insufficienti.
2. Meccanismo di Correzione con Enforcement dei Vincoli: Un innovativo processo di riparazione in due fasi che impone vincoli a livello di simbolo, protocollo e iterazione. Crucialmente, la seconda fase richiede al modello di generare una giustificazione strutturata per le sue correzioni, prendendo di mira direttamente le allucinazioni di "non seguire".
3. Primo Approccio LLM Senza Mocking per Java: MocklessTester è presentato come il primo approccio basato su LLM per Java che mira esplicitamente alle dipendenze esterne, facendo avanzare il testing automatizzato dal testing unitario con mocking verso un'esecuzione realistica.
4. Valutazione Empirica Completa: Lo studio introduce la Copertura delle Righe di Dipendenza (DepLC) come nuova metrica per misurare l'estensione del codice reale del progetto esercitato oltre la Classe Sotto Test (CUT).

Risultati Sperimentali

L'approccio è stato valutato su Defects4J (14 progetti, 130 classi) e su un nuovo benchmark, Deps4J (5 progetti recenti multi-modulo, 30 classi), confrontandolo con la baseline all'avanguardia PANTA.

• Efficacia:

  • Su Defects4J, MocklessTester ha migliorato la copertura media delle righe del 19,99% (da 68,83% a 88,82%) e la copertura dei rami del 24,90% (da 58,84% a 83,74%). Il punteggio di mutazione è aumentato del 13,67%.
  • Su Deps4J, ha migliorato la copertura delle righe del 22,69% e la copertura dei rami del 15,78%, mantenendo punteggi di mutazione comparabili.
  • Copertura delle Dipendenze: MocklessTester ha coperto significativamente più codice di dipendenza reale, aumentando la DepLC del progetto di 378 righe su Defects4J e di 55 righe su Deps4J rispetto alla baseline.
  • Efficienza dei Test: Nonostante generi in media meno test per progetto, MocklessTester ha raggiunto una copertura superiore, indicando una qualità superiore per test.

• Efficienza:

  • MocklessTester ha sostenuto costi totali di token e tempo più elevati a causa dell'esecuzione di più iterazioni per raggiungere una copertura superiore.
  • Tuttavia, il costo rimane pratico: una media di 108,97 secondi e 26.590 token per metodo su Defects4J.
  • Degno di nota, MocklessTester è stato sostanzialmente più veloce per iterazione (circa il 58% in meno di tempo) rispetto alla baseline, suggerendo che le sue iterazioni sono più efficienti nel tempo anche se più numerose.

• Studio di Ablazione:

  • La rimozione del Recupero dell'Uso ha causato il calo più grande nelle prestazioni, confermando l'importanza del contesto.
  • La rimozione dei vincoli a livello di protocollo ha avuto il secondo impatto più grande, evidenziando la difficoltà di gestire oggetti con stato senza enforcement esplicito.
  • Anche i vincoli a livello di simbolo e di iterazione hanno fornito miglioramenti significativi, sebbene leggermente inferiori.

Significato e Affermazioni

Il documento afferma che MocklessTester affronta con successo le limitazioni del testing basato su mocking consentendo la generazione di test che esercitano le dipendenze reali del progetto. Affrontando sistematicamente il "non conoscere" attraverso l'arricchimento del contesto e il "non seguire" attraverso l'enforcement dei vincoli, l'approccio ottiene risultati all'avanguardia nella copertura delle righe, nella copertura dei rami e nel punteggio di mutazione su benchmark consolidati e nuovi.

Gli autori sottolineano che, sebbene l'approccio richieda risorse computazionali superiori rispetto ai metodi baseline, il compromesso produce test non solo più completi nella copertura, ma anche più robusti rispetto all'evoluzione delle dipendenze. L'introduzione della DepLC fornisce una nuova dimensione per la valutazione delle suite di test, andando oltre la CUT per misurare l'esecuzione effettiva del sistema più ampio. Il lavoro suggerisce che i futuri miglioramenti potrebbero coinvolgere meccanismi di memoria più ricchi e la generazione di input consapevoli della grammatica per componenti centrati sul parser.