Understanding Self-Admitted Technical Debt in Test Code: An Empirical Study
Questo studio empirico investiga la distribuzione, le tipologie e la relazione con la qualità dei test del Debito Tecnico Auto-Ammesso (SATD) nel codice di test attraverso 50 repository, rivelando che, sebbene il SATD sia diffuso e distinto dal SATD del codice di produzione, non è direttamente associato ai test smells, e dimostrando che un modello basato su CodeBERT classifica efficacemente questi tipi di debito per una migliore gestione.
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 lo sviluppo di un software come la costruzione di una casa enorme e complessa. A volte, per rispettare una scadenza o per lanciare rapidamente un prototipo, i costruttori (gli sviluppatori) prendono delle scorciatoie. Potrebbero usare una porta temporanea invece di una solida, o lasciare una stanza finita male con un post-it attaccato al muro che dice: "Sistemare questo più tardi". Nel mondo della programmazione, queste scorciatoie sono chiamate Debito Tecnico (Technical Debt), e i post-it sono chiamati Debito Tecnico Auto-amministrato (Self-Admitted Technical Debt o SATD).
Per anni, i ricercatori hanno studiato questi post-it, ma si sono concentrati principalmente sui biglietti attaccati alle pareti del soggiorno (il codice di produzione principale). Hanno ampiamente ignorato i biglietti attaccati ai disegni tecnici e alle liste di controllo delle ispezioni (il codice di test). Questo articolo decide di pulire finalmente la cassetta degli attrezzi e guardare specificamente ai biglietti trovati nel codice di test.
Ecco cosa hanno scoperto i ricercatori, spiegato in modo semplice:
1. I Post-it sono ovunque (anche nella stanza dei test)
I ricercatori hanno esaminato 50 diversi progetti software (come un quartiere composto da 50 diverse case). Hanno scoperto che, sebbene ci siano meno post-it nel codice di test rispetto al codice principale, ce ne sono comunque molti: circa il 15,6% di tutti i biglietti trovati era nel codice di test.
L'analogia: Se il codice principale è la struttura della casa, il codice di test è la lista di controllo dell'ispettore. Lo studio ha scoperto che gli ispettori sono altrettanto propensi a scarabocchiare "Controllare questo più tardi" sulle loro liste quanto i costruttori sulle pareti. Non è una quantità piccola o trascurabile; è una parte significativa del lavoro.
2. I biglietti non corrispondono agli "odori"
Nel software, esistono strumenti automatizzati che fiutano i "cattivi odori" nel codice di test — come un test troppo lungo, confuso o instabile (a volte passa, a volte fallisce). Questi sono chiamati Test Smells (Odori del Test).
I ricercatori volevano vedere se i post-it (SATD) venissero solitamente trovati proprio accanto a questi cattivi odori.
- Il risultato: Sorprendentemente, no. I post-it e i cattivi odori compaiono solitamente in posti diversi.
- L'analogia: Immagina un ispettore edile. I "cattivi odori" sono come un odore di muffa in una cantina (un problema strutturale rilevato dalla macchina). I "post-it" sono come un appunto scritto a mano che dice: "Non ho finito di dipingere questa parete". Lo studio ha scoperto che i luoghi con l'odore di muffa non erano necessariamente gli stessi dei biglietti relativi alla pittura non finita. Gli sviluppatori segnalano problemi che gli strumenti di "fiuto" automatizzati stanno perdendo.
3. Cosa dicono realmente i biglietti?
Il team ha letto a mano 506 di questi post-it del codice di test per capire di cosa si lamentassero realmente gli sviluppatori. Li ha classificati in un nuovo "dizionario" di 20 diversi tipi di problemi, raggruppati in 5 categorie principali:
- Problemi legati alla produzione: Note che dicono: "Questo test fallirà se lo esegui su Windows", o "Non posso finire questo test perché il codice principale ha un bug".
- Test incompleti: La nota più comune: "Ho iniziato questo test, ma non ho finito di scrivere la parte che controlla se il risultato è corretto".
- Cattiva progettazione/Soluzioni temporanee (Workarounds): Note come: "Ho dovuto usare un trucco poco pulito per far funzionare questo test perché il codice è troppo bloccato", o "Questo test è scritto in modo goffo".
- Manutenzione: Note che dicono: "Questo test è instabile (flaky)", "Dobbiamo aggiornarlo per la nuova versione del software", o "Questo test è inutile, cancellalo".
- Dubbi: Note che chiedono: "A cosa serve questo test?" o "Ho davvero bisogno di questo timer di sospensione?".
La grande conclusione: La maggior parte di questi biglietti riguarda il lavoro incompleto. Gli sviluppatori spesso scrivono un test ma si fermano prima di aggiungere l'ultimo controllo, lasciando un appunto per finirlo più tardi.
4. Un robot può leggere questi biglietti?
I ricercatori hanno cercato di insegnare ai computer a leggere questi post-it e a classificarli automaticamente nelle categorie corrette. Hanno provato diverse "intelligenze" (algoritmi), incluse alcune molto avanzate basate sull'IA.
- Il vincitore: Un modello di IA specializzato chiamato CodeBERT è stato il migliore nel compito. Ha identificato correttamente il tipo di debito circa il 70% delle volte.
- La sorpresa: Un'IA più recente e potente (GPT-4) è stata in realtà migliore nel trovare i biglietti rari e strani che gli altri avevano mancato, anche se non è stata la più costante in termini generali.
- Il problema: L'IA ha avuto più difficoltà con la categoria "Fallimenti" (note sui test che falliscono). Ciò è dovuto in parte al fatto che c'erano pochissimi esempi di questi biglietti nei loro dati, rendendo difficile per il robot imparare il modello.
Riassunto
Questo articolo ci dice che il codice di test ha il suo set unico di "affari incompiuti" che è diverso dal codice principale. Gli sviluppatori scrivono note su test incompleti, cattive progettazioni e risultati instabili che gli strumenti automatizzati non stanno rilevando. Sebbene possiamo ora usare l'IA per aiutare a classificare questi biglietti, la tecnologia ha ancora bisogno di fare pratica, specialmente sui casi rari e complicati.
La lezione principale è: Non ignorate i biglietti sulle liste di controllo dei test. Essi rivelano un tipo diverso di disordine nel software che richiede un tipo diverso di pulizia.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.