On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems

Sintesi Tecnica: Sulla natura instabile (flakiness) dei test generati da LLM per sistemi di gestione di database industriali e open-source

Definizione del Problema
I test instabili (flaky tests), che producono risultati inconsistenti quando vengono eseguiti più volte sullo stesso stato del codice, rappresentano una sfida significativa nel testing del software industriale, riducendo l'efficienza e minando la fiducia degli sviluppatori. Sebbene studi recenti abbiano identificato l'instabilità come un potenziale problema nei test generati da modelli linguistici di grandi dimensioni (LLM), la prevalenza, le cause radici e i meccanismi di trasferimento dell'instabilità in questo contesto rimangono poco chiari. Questo studio affronta il vuoto nella ricerca dedicata all'instabilità dei test generati da LLM, specificamente nel contesto dei Database Management Systems (DBMS), dove l'affidabilità dei test è critica per le operazioni aziendali.

Metodologia
Gli autori hanno condotto uno studio empirico coinvolgendo quattro DBMS: il sistema industriale a codice chiuso SAP HANA, e tre sistemi open-source (MySQL, DuckDB e SQLite). Lo studio si è concentrato su due tipi di test: unit test nativi in C++ e test di sistema SQL.

• Approccio alla Generazione dei Test: I ricercatori hanno adottato una strategia di amplificazione dei test ispirata a Alshahwan et al. [5], istruendo (prompting) gli LLM a generare versioni estese di file di test esistenti per coprire casi limite (corner cases) aggiuntivi.
• Modelli: Sono stati valutati due LLM: GPT-4o (selezionato per le sue alte prestazioni e capacità di gestire il codice interno di SAP HANA) e Mistral-Large-Instruct-2407 (selezionato come alternativa open-source per la riproducibilità). Entrambi i modelli sono stati eseguiti con una temperatura pari a zero per massimizzare i tassi di successo della compilazione.
• Ambiente di Esecuzione: Per isolare l'instabilità causata dal codice generato piuttosto che dal rumore ambientale, i test sono stati eseguiti 30 volte ciascuno all'interno di container Docker isolati. I test C++ sono stati eseguiti singolarmente, mentre i test SQL sono stati eseguiti in ordine di file per rispettare il design dei rispettivi framework di test.
• Rilevamento dell'Instabilità: Un test è stato classificato come instabile se ha prodotto sia risultati positivi che negativi nell'arco delle 30 esecuzioni.
• Esperimento di Trasferimento dell'Instabilità: Per valutare la suscettibilità al "trasferimento dell'instabilità", gli autori hanno iniettato un'asserzione non deterministica (che fallisce con una probabilità del 50%) nei file di test esistenti prima di istruire gli LLM a generare nuovi test.

Contributi Chiave

1. Analisi della Prevalenza: Una valutazione quantitativa della proporzione di test instabili nel codice generato da LLM rispetto ai test esistenti scritti da umani attraverso quattro DBMS.
2. Identificazione delle Cause Radici: Un'ispezione manuale e una categorizzazione delle cause radici dell'instabilità nei test generati da LLM, distinguendo tra problemi derivanti dal processo di generazione e quelli trasferiti dal contesto.
3. Benchmark di Trasferimento dell'Instabilità: Una valutazione sperimentale del grado in cui gli LLM trasferiscono pattern instabili dagli esempi forniti nel contesto al nuovo codice generato, confrontando le prestazioni tra contesti a codice chiuso (SAP HANA) e open-source (MySQL).

Risultati

• Tassi di Compilazione e Successo: Gli LLM hanno incontrato difficoltà significative nel generare codice C++ compilabile per il progetto a codice chiuso SAP HANA (Tasso di Successo della Compilazione di circa il 40-46%), a causa della mancanza di dati di addestramento del modello su quel codice specifico. Al contrario, la generazione di test SQL ha mostrato alti tassi di successo (81-95%).
• Prevalenza dell'Instabilità: La proporzione di test instabili nel codice generato da LLM è stata generalmente leggermente superiore rispetto ai test esistenti.
  • Per i test C++, GPT-4o ha generato lo 0,29% di test instabili per SAP HANA e lo 0,18% per MySQL, mentre Mistral ha generato tassi leggermente superiori (rispettivamente 0,39% e 0,71%).
  • Per i test SQL, dove non sono stati trovati test instabili preesistenti nelle suite originali, gli LLM hanno generato in totale 96 test instabili (43 da parte di GPT-4o, 53 da parte di Mistral).
• Cause Radici: La causa più prevalente di instabilità nei test generati da LLM è stata l'"Unordered Collection" (Collezione non ordinata) (63% di 115 test instabili). Ciò si è verificato quando gli LLM hanno generato query SQL assumendo un ordine specifico dei risultati senza utilizzare ORDER BY, portando a fallimenti intermittenti.
  • L'instabilità da NIO (Non-Idempotent Outcome) è stata la seconda causa più comune (10%), spesso derivante dal fatto che l'LLM imitava i test esistenti che inquinavano l'ambiente di esecuzione.
  • Problemi di concorrenza sono stati osservati principalmente nei test generati da Mistral.
• Trasferimento dell'Instabilità: Entrambi gli LLM hanno dimostrato suscettibilità al trasferimento dell'instabilità iniettata dal contesto del prompt ai test generati.
  • Nel contesto SAP HANA (codice chiuso, assenza di dati di addestramento), il tasso di trasferimento è stato più alto (~69-78% dei test generati conteneva l'asserzione instabile iniettata).
  • Nel contesto MySQL (open-source, probabilmente presente nei dati di addestramento), il tasso di trasferimento è stato inferiore (~41-58%).
  • Ciò suggerisce che gli LLM si affidano maggiormente al contesto fornito quando mancano di conoscenze pregresse del sistema, rischiando di adottare correlazioni spurie (come le asserzioni instabili) come pattern di codifica validi.

Significatività e Rivendicazioni
Il documento sostiene di fornire i primi approfondimenti dedicati sull'instabilità dei test generati da LLM per i sistemi di database. Gli autori concludono che, sebbene gli LLM possano generare codice di test dall'aspetto naturale, essi introducono rischi specifici di instabilità, in particolare riguardo alle strutture dati non ordinate e al trasferimento di difetti esistenti.

Lo studio evidenzia che il trasferimento dell'instabilità è un problema critico, specialmente negli ambienti a codice chiuso dove i modelli mancano di dati di addestramento e si affidano pesantemente all'apprendimento nel contesto (in-context learning). Di conseguenza, gli autori consigliano ai professionisti di dare priorità alla risoluzione dei test instabili esistenti prima di applicare approcci di generazione basati su LLM per evitare la propagazione dell'instabilità. Essi sottolineano inoltre la necessità di fornire agli LLM un contesto su misura per mitigare cause radici come le assunzioni di "collezione non ordinata", notando che gli attuali finestrini di contesto potrebbero essere insufficienti per sistemi grandi come SAP HANA. Le scoperte servono come base cautelativa per sviluppatori e ricercatori che mirano a integrare gli LLM nelle pipeline di testing automatizzato.