💻 computer science

Heterogeneous Prompting and Execution Feedback for SWE Issue Test Generation and Selection

Questo articolo introduce e-Otter++, un nuovo generatore di test che supera la sfida del codice mancante o errato nelle problematiche di ingegneria del software sfruttando il prompting etogeneo e il feedback di esecuzione per creare automaticamente test di riproduzione, raggiungendo un tasso di fail-to-pass allo stato dell'arte del 63% sul benchmark TDD-Bench Verified.

Autori originali: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Pubblicato 2026-01-26

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere un detective che cerca di risolvere un mistero in una biblioteca enorme e disordinata (il codice software). Un utente (lo sviluppatore) viene da te e dice: "Qualcosa non va in questo libro, ma non riesco a spiegare esattamente cosa, e non ho un esempio specifico del problema che accade".

Nel mondo del software, questo è chiamato un problema SWE. Di solito, per correggere un bug, serve un "test di riproduzione" (reproduction test): uno script specifico che dica: "Se fai X, la libreria dovrebbe crashare". Questo prova che il bug esiste. Ma spesso, questi script non esistono ancora.

Questo articolo presenta un nuovo strumento per detective chiamato e-Otter++. Il suo compito è scrivere automaticamente quel "test di crash" (lo script) leggendo semplicemente la descrizione disordinata del problema, ancor prima che la correzione vera e propria sia stata scritta.

Ecco come funziona e-Otter++, spiegato attraverso semplici analogie:

1. Il Problema: Il Detective "Cieco"

Di solito, se chiedi a un'IA intelligente (un Large Language Model) di scrivere un test, essa cerca di indovinare. Se glielo chiedi una volta, potrebbe sbagliare. Se glielo chiedi 10 volte con le stesse identiche istruzioni, potrebbe semplicemente darti 10 versioni leggermente diverse dello stesso errore. È come chiedere a un amico di descrivere un film che ha visto una sola volta; se glielo chiedi 10 volte, probabilmente ripeterà lo stesso errore.

2. Il Primo Trucco: "Heterogeneous Prompting" (La Festa in Maschera)

Per ottenere ipotesi migliori, e-Otter++ non si limita a chiedere all'IA la stessa domanda 10 volte. Invece, cambia il modo in cui pone la domanda, come se mettesse l'IA in diversi costumi o le desse diverse prospettive.

Le "Maschere": Immagina che l'IA stia guardando un puzzle. A volte, e-Otter++ copre parti del puzzle (il contesto del codice) in modo che l'IA debba indovinare basandosi su meno informazioni. Altre volte, mostra solo pezzi specifici. Questo costringe l'IA a guardare il problema in modo diverso.
I "Morphs": Immagina che il rapporto sul bug sia scritto in un gergo confuso. e-Otter++ chiede all'IA di riscrivere il rapporto in stili diversi:
- Lo "Standardizzatore": Trasforma una nota disordinata in un rapporto formale e strutturato.
- Il "Semplificatore": Rimuove il gergo tecnico confondente per renderlo facile da capire.
- Il "Dropper": Rimuove specifici frammenti di codice che potrebbero essere fuorvianti (come dire all'IA di usare uno strumento che la libreria non possiede realmente).
- Il "Pre-Pensatore": Chiede all'IA di indovinare prima una soluzione, per poi usare quell'ipotesi per scrivere il test.

Combinando questi "Masks" e "Morphs", e-Otter++ genera un pool enorme e diversificato di potenziali test. È come chiedere a 10 persone diverse di descrivere una scena del crimine, ma dando a ciascuna una serie diversa di indizi e un modo diverso di parlare. Questo aumenta la probabilità che almeno una di loro indovini.

3. Il Secondo Trucco: "Execution Feedback" (La Prova Generale)

Una volta che l'IA ha generato un test, e-Otter++ non si fida ciecamente. Esegue il test sul codice vecchio (la versione con il bug).

L'Obiettivo: Il test deve fallire. Ma deve fallire per il motivo giusto.
Il Problema: A volte il test fallisce a causa di un errore banale (come un refuso), non a causa del bug reale.
La Soluzione: e-Otter++ ha un "Critico" (un'altra IA) che esamina il fallimento. Se il test è fallito per il motivo sbagliato, il Critico dice: "No, quello non è il bug. Ecco la riga specifica che è errata, ed ecco del codice extra che devi guardare". Quindi il sistema riscrive il test con queste nuove informazioni. Continua questo ciclo finché il test non fallisce esattamente come previsto dalla descrizione del bug.

4. Il Terzo Trucco: Il "Surrogate Patch" (La Correzione Finta)

Questa è la parte più difficile: per sapere se un test è buono, deve passare sul codice nuovo (la correzione). Ma la correzione non esiste ancora! Come si può scegliere il test migliore?

e-Otter++ usa un astuto aggiramento:

Chiede a un altro sistema di IA (chiamato Agentless) di generare un sacco di correzioni finte (surrogate patches). Queste non sono perfette, ma sono vicine all'originale.
Esegue tutti i test candidati contro queste correzioni finte.
Se un test passa sulla correzione finta, è probabile che sia un buon test.
Infine, sceglie il singolo test migliore in base a quale copre le parti più importanti del codice.

I Risultati: Un Grande Salto in Avanti

Il paper ha testato questo sistema su due benchmark principali (TDD-Bench e SWT-bench).

Il Migliore Precedente: I sistemi precedenti riuscivano a generare un test funzionante circa il 37% - 38% delle volte.
e-Otter++: Usando questi nuovi trucchi (cambiare il modo in cui si pongono le domande e usare correzioni finte per filtrare le risposte), e-Otter++ ha alzato il tasso di successo al 63% in un benchmark e al 52,5% nell'altro.

Perché Questo è Importante

Gli autori affermano che questo aiuta in due modi principali:

Per gli Umani: Automatizza la parte noiosa dello "Sviluppo Guidato dai Test" (scrivere i test prima di correggere i bug), rendendo più facile per i programmatori confermare i bug e correggerli.
Per gli Agenti IA: Molti agenti di programmazione basati su IA si affidano a questi test per sapere se hanno corretto un bug. Fornendo test migliori, e-Otter++ aiuta anche gli altri agenti IA a svolgere meglio il proprio lavoro.

In breve, e-Otter++ è un modo più intelligente, creativo e rigoroso per chiedere all'IA di scrivere la "prova" che un bug software esiste e che è stato corretto, senza che un essere umano debba scrivere prima quella prova.

Sintesi Tecnica: Prompting Eterogeneo e Feedback di Esecuzione per la Generazione e Selezione di Test per Issue di SWE

Problematica
Le issue di Ingegneria del Software (SWE), che descrivono bug o funzionalità mancanti, sono spesso accompagnate da descrizioni informali prive di test di riproduzione automatizzati. L'assenza di tali test ostacola la verifica delle issue e l'accettazione delle patch di codice. La sfida specifica affrontata in questo articolo è la generazione automatica di test di riproduzione "fail-to-pass" ( $F \to P$ ) direttamente dalle descrizioni delle issue e dal codice esistente (pre-patch) ( $c_{old}$ ), senza accesso alla patch di risoluzione ( $c_{new}$ ). Un test $F \to P$ valido deve fallire durante l'esecuzione su $c_{old}$ (riproducendo l'issue) e passare quando eseguito su $c_{new}$ (confermando la correzione). Questo compito è difficile perché le descrizioni delle issue sono informali e il codice target per cui il test deve passare non esiste ancora.

Metodologia: e-Otter++
Gli autori introducono e-Otter++, un sistema che estende il precedente framework Otter++. Il sistema opera attraverso tre componenti primari: un generatore di test, un generatore di patch di codice e un selettore di test.

Generazione di Test con Prompting Eterogeneo:
Invece di fare affidamento esclusivamente sull'aumento della temperatura di decodifica degli LLM per generare candidati diversificati (una pratica comune che spesso manca di diversità), e-Otter++ impiega il prompting eterogeneo. Questo comporta due variazioni sistematiche:
- Morph della Descrizione dell'Issue: Un LLM riscrive la descrizione originale dell'issue in cinque modi distinti prima della generazione del test: standard (formattazione), simple (semplificazione del gergo), dropCode (rimozione di potenziali snippet di codice fuorvianti), initTest (incorporazione di un test iniziale) e initPatch (incorporazione di una proposta di patch iniziale).
- Maschere di Contesto: Il prompt di generazione del test viene modificato per includere o escludere specifici contesti di localizzazione (ad esempio, output del planner, localizzazione del test, localizzazione della patch), creando cinque distinte variazioni di prompt.
  Combinando questi elementi, il sistema genera un pool diversificato di 10 test candidati per ogni issue.
Riparazione dei Test Aumentata dall'Esecuzione:
I test candidati generati vengono eseguiti su $c_{old}$ . Sebbene ci si aspetti che falliscano, potrebbero fallire per ragioni errate (ad esempio, errori di sintassi o eccezioni non correlate) piuttosto che riprodurre l'issue specifica descritta. e-Otter++ introduce un meccanismo di critica (critic):
- Un LLM analizza la descrizione dell'issue e il log di esecuzione per determinare se il test fallisce per la "ragione corretta".
- Se il fallimento è errato, il critico identifica il contesto necessario (ad esempio, righe buggate specifiche, snippet di codice rilevanti o firme di funzioni) e aumenta il prompt di riparazione.
- Il sistema ripara iterativamente il test (fino a 10 tentativi) utilizzando questo contesto arricchito finché il test non fallisce per la ragione corretta o finché non viene raggiunto il limite di iterazione.
Selezione dei Test tramite Patch Surroghe:
Poiché $c_{new}$ non è disponibile, e-Otter++ non può verificare direttamente se un test passa su la vera correzione. Per risolvere questo problema, il sistema utilizza Agentless per generare 40 patch di codice candidate (surrogati per $c_{new}$ ) e le filtra riducendole alle 5 più frequenti.
- Il selettore di test esegue i test candidati su queste patch surroghe.
- I test che sono $F \to P$ sulle patch surroghe vengono prioritizzati.
- Un selettore basato su regole classifica i fallimenti (assertion failures rispetto a errori) e utilizza la copertura del codice (la proporzione di righe aggiunte/rimosse dalla patch che il test copre) come criterio di spareggio per selezionare il singolo test finale.

Contributi Chiave
Il documento presenta tre contributi innovativi:

Riparazione dei Test Aumentata dall'Esecuzione: Un metodo per aumentare la correttezza dei test utilizzando il feedback di esecuzione per recuperare codice correlato e aumentare il prompt di riparazione, garantendo che i test falliscano per le ragioni specificate nell'issue.
Prompting Eterogeneo per la Diversità: Aumentare la diversità dei test candidati attraverso morph della descrizione dell'issue e maschere di contesto, invece di fare affidamento solo sul campionamento ad alta temperatura.
Selezione Basata su Patch Surroghe: Una tecnica per selezionare il test finale utilizzando il feedback di esecuzione da patch di codice imperfette e generate come proxy per la correzione reale (ground-truth).

Risultati
Il sistema è stato valutato su TDD-Bench Verified (449 campioni) e SWT-bench Lite (276 campioni), entrambi derivati da SWE-bench.

Performance: e-Otter++ ha raggiunto un tasso di Fail-to-Pass ( $F \to P$ ) allo stato dell'arte del 63,0% su TDD-Bench Verified e del 52,5% su SWT-bench Lite (utilizzando il modello Claude-3.7-Sonnet). Questo supera significativamente i precedenti migliori risultati pubblicati (Otter++ al 37,0% e 29,0%, rispettivamente).
Efficacia dei Componenti:
- La riparazione aumentata dall'esecuzione ha migliorato i tassi di $F \to P$ dell'11,1% fino al 74,3% attraverso diverse configurazioni.
- Il prompting eterogeneo (morph + maschere) ha aumentato il $F \to P@N$ (tasso di almeno un test riuscito tra $N$ candidati) di oltre il 13% rispetto all'uso delle sole maschere.
- L'uso di patch di codice generate come pre-filtro per la selezione del test ha fornito un aumento significativo delle prestazioni (ad esempio, un aumento del 32,9% del $F \to P$ su TDD-Bench Verified).
Generalizzabilità: L'approccio è stato convalidato su SWE-rebench, un benchmark privo di contaminazione, dove ha migliorato il tasso di $F \to P$ di un 75% relativo rispetto al sistema base Otter, dimostrando robustezza contro la contaminazione dei dati.
Utilità di Validazione: È stato dimostrato che i test generati validano efficacemente le patch di codice di altri agenti SWE, migliorando significativamente la precisione delle soluzioni proposte dai principali sistemi in classifica.

Significato e Rivendicazioni
Gli autori sostengono che e-Otter++ rappresenti un salto sostanziale nello stato dell'arte per la generazione di test di riproduzione da issue di SWE. L'articolo argomenta che la combinazione di prompting eterogeneo e feedback di esecuzione — specificamente l'uso innovativo di patch surroghe per la selezione e la riparazione del contesto aumentato — supera i limiti dei metodi precedenti che faticavano con la diversità dei test e la mancanza di un codebase target per la verifica.

Il lavoro mira a consolidare la pratica dello Sviluppo Guidato dai Test (TDD) automatizzando la creazione tediosa di test di riproduzione, aiutando così sia gli ingegneri umani che gli agenti SWE automatizzati nella risoluzione delle issue e nella gestione della qualità a lungo termine. Gli autori rimangono modesti riguardo all'ambito, osservando che il sistema attualmente gestisce singoli file di test ed è valutato principalmente su Python, ma sottolineano che i miglioramenti relativi suggeriscono che le tecniche siano efficaci anche su dataset diversi e non contaminati.