TestMap: Evidence Infrastructure for Foundation-Model-Assisted Test Generation

Sintesi Tecnica: TestMap – Infrastruttura di Evidenza per la Generazione di Test Assistita da Modelli Fondazionali

Definizione del Problema
I modelli fondazionali (FM) sono sempre più capaci di generare unit test plausibili; tuttavia, determinare la loro correttezza, utilità, manutenibilità e valore di integrazione rimane una sfida significativa. Il problema centrale è un problema di "validazione ricorsiva": i test generati sono sia artefatti di codice che artefatti di validazione. Devono essere validati prima di poter essere considerati affidabili per validare il sistema sotto test. Attualmente, il processo di validazione è frammentato tra strumenti disparati (sistemi di build, test runner, strumenti di coverage, strumenti di mutazione, analizzatori statici), che spesso riportano solo esiti aggregati piuttosto che collegare l'evidenza ai singoli candidati di test. Inoltre, gli approcci esistenti spesso scartano i candidati falliti o intermedi, perdendo dati preziosi riguardanti i limiti del modello, la mancanza di contesto o potenziali difetti nel sistema sotto test.

Metodologia: L'Infrastruttura TestMap
Il documento presenta TestMap, un prototipo di infrastruttura open-source progettato per automatizzare la generazione e la valutazione di test assistiti da FM basati su evidenze, mirando specificamente a repository C#/.NET. TestMap tratta i test generati come "candidati" piuttosto che come risposte definitive, registrando il loro intero ciclo di vita.

Il sistema opera attraverso una pipeline strutturata:

1. Ingestione del Repository e Analisi Statica: TestMap clona un repository target, utilizza le API Roslyn per analizzare la soluzione e svolge un'analisi statica per mappare il codice sorgente, le dipendenze e le strutture dei test. Raccoglie metriche del codice e rileva i "test smells" (utilizzando una versione personalizzata di xNose).
2. Esecuzione Baseline: Prima della generazione, viene eseguita l'attuale suite di test per stabilire una baseline di copertura, punteggi di mutazione ed esiti di esecuzione.
3. Selezione del Target e Costruzione del Contesto: I target di generazione (ad esempio, metodi sorgente) sono selezionati in base a criteri configurabili come linee non coperte, mutanti sopravvissuti o test correlati. Viene costruito un "pacchetto di evidenza", che include il codice target, i test correlati, le lacune di copertura e le convenzioni del framework.
4. Generazione Guidata dal Modello: TestMap impiega una pipeline di generazione decomposta (ispirata a RUG) invece di una generazione a prompt singolo. Suddivide il compito in fasi di pianificazione (pianificazione degli scenari, denominazione dei metodi, arrangement, pianificazione degli input, pianificazione dell'azione, pianificazione delle asserzioni) seguite dalla sintesi finale. Supporta diversi modi di contesto (ad esempio, NoHistory rispetto a ChainedHistory) e budget pass@k.
5. Validazione e Riparazione: I candidati generati sono sottoposti a validazione pre-esecuzione (estrazione della sintassi, inserimento, diagnostica del compilatore) e validazione post-esecuzione (build, esecuzione, coverage, mutazione). I candidati falliti non vengono scartati; vengono preservati con i relativi dati diagnostici. Se abilitato, un ciclo di riparazione utilizza gli errori del compilatore, i log di esecuzione e i fallimenti delle asserzioni per sollecitare il modello a revisioni.
6. Persistenza delle Evidenze: Tutti gli artefatti — inclusi prompt, risposte del modello, log di build, risultati di esecuzione, delta di coverage, esiti di mutazione e cronologie di riparazione — sono persistiti in un database SQLite. Ciò consente un'analisi granulare dei singoli candidati e dei confronti tra strategie aggregate.

Contributi Chiave
Il documento apporta i seguenti contributi:

1. Inquadramento del Problema: Inquadra la generazione di test assistita da FM come un problema di validazione ricorsiva in cui i test generati devono essere validati prima di servire come evidenza.
2. Prototipo TestMap: Introduce un'infrastruttura di evidenza open-source che automatizza l'analisi del repository, la validazione dei candidati, la raccolta di evidenze, il tracciamento delle riparazioni e il logging degli esperimenti.
3. Preservazione del Ciclo di Vita: Il sistema preserva l'intero ciclo di vita dei candidati, inclusi i risultati falliti, riparati, a basso impatto ed evidenzialmente positivi, consentendo lo studio dei risultati intermedi.
4. Esperimenti Specifici per Repository: Facilita esperimenti che confrontano modelli, prompt, strategie di generazione e workflow di riparazione su basi di codice concrete, andando oltre i benchmark standardizzati.
5. Modello di Evidenza: Definisce un modello di evidenza strutturato che collega i candidati al contesto del repository, ai parametri di generazione, agli esiti di esecuzione e agli indicatori di qualità.

Risultati e Scoperte
Il documento non presenta uno studio empirico su larga scala con metriche quantitative di performance (ad esempio, "TestMap ha migliorato la copertura del X%"); invece, i "risultati" sono la dimostrazione della capacità dell'infrastruttura di:

• Ingerire e analizzare con successo repository C#/.NET reali.
• Eseguire l'intera pipeline dalla generazione alla validazione, inclusa la gestione dei fallimenti di build ed errori di esecuzione.
• Persistere cronologie dettagliate dei candidati, distinguendo tra esiti ValidationFailed, Validated, ValidatedLowImpact e ValidatedEvidencePositive.
• Supportare confronti specifici per repository tra diverse strategie di generazione (ad esempio, prompting ingenuo rispetto a prompting guidato dalle metriche).

Gli autori osservano che l'infrastruttura rivela che i test generati richiedono spesso riparazioni e che i candidati falliti forniscono evidenze critiche riguardo alla qualità dell'oracle, alle lacune di contesto e alle inefficienze del toolchain.

Significatività e Rivendicazioni
Il documento sostiene che TestMap affronti un vuoto critico nelle infrastrutture di ingegneria del software. La sua significatività risiede nello spostare il focus dal semplice produrre test eseguibili al rendere i test generati osservabili, ripetibili e confrontabili.

• Oltre i Benchmark: TestMap integra i benchmark standardizzati fornendo evidenze su come la generazione assistita da FM si comporti sotto i vincoli effettivi di un repository specifico (sistemi di build, dipendenze, stili di test esistenti).
• Evidenza per il Processo Decisionale: Preservando i candidati falliti e riparati, lo strumento supporta la revisione da parte degli sviluppatori e l'analisi empirica, aiutando a distinguere tra limitazioni del modello, problemi del toolchain e reali difetti del sistema.
• Direzione Futura: Gli autori concludono che il futuro della generazione di test assistita da FM richiede un'infrastruttura che non solo generi test, ma fornisca anche l'evidenza necessaria per decidere se tali test siano utili, manutenibili e affidabili. TestMap è presentato come un passo verso questa infrastruttura di evidenza, riconoscendo le sfide aperte come la qualità delle asserzioni, la flakiness, l'attribuzione delle metriche e l'accettazione da parte degli sviluppatori.

Il documento mantiene un tono modesto, dichiarando esplicitamente che l'attuale prototipo non studia direttamente le decisioni degli sviluppatori né misura i miglioramenti nella calibrazione della fiducia, bensì fornisce l'infrastruttura dati necessaria per tali studi futuri.