A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection

Il software non è mai veramente finito. Anche dopo il rilascio di un programma, gli sviluppatori devono tornarvi costantemente per correggere errori, aggiungere nuove funzionalità e adattarsi a esigenze mutevoli. Questo lavoro continuo è chiamato manutenzione, e spesso richiede più sforzo della creazione iniziale del software stesso. Per rendere gestibile questo lavoro, i programmatori a volte lasciano note nel loro codice, ammettendo che una particolare sezione è disordinata, temporanea o non del tutto corretta. Potrebbero scrivere un commento dicendo: "Questo è un rimpiazzamento approssimativo" (hack), o "Correggere più tardi". Nel mondo dell'ingegneria del software, queste ammissioni oneste sono note come debito tecnico auto-amministrato. Sono come uno sviluppatore che dice: "So che questo non è il modo migliore per farlo, ma dovevamo finire subito". Mentre i ricercatori studiano da tempo queste note nel codice principale che esegue un programma, hanno ampiamente ignorato le note trovate nel codice utilizzato per testare quel programma. Questa è una significativa svista, perché se i test stessi sono difettosi o scritti male, l'intero sistema software diventa inaffidabile.

Un team di ricercatori dell'Università del Manitoba si è posto l'obiettivo di comprendere questo strato nascosto di debito. Si sono concentrati su un tipo specifico di software scritto in Java, un linguaggio ampiamente utilizzato per costruire applicazioni complesse. Per ottenere un quadro chiaro, hanno raccolto una collezione massiccia di oltre un milione di commenti da mille diversi progetti open-source. Da questo vasto pool, hanno selezionato casualmente cinquantamila commenti da esaminare manualmente. Questa revisione manuale è stata un lavoro faticoso, che ha richiesto ai ricercatori di leggere ogni nota e decidere se rappresentasse una vera ammissione di un problema o solo una spiegazione standard. Dopo aver filtrato i commenti che non erano rilevanti o che provenivano da un singolo progetto che sbilanciava i dati, hanno identificato 615 commenti che erano veri esempi di debito tecnico nel codice di test.

I ricercatori hanno scoperto che la natura di questi debiti nel codice di test è quite diversa da quella che si trova nel codice dell'applicazione principale. Hanno suddiviso i 615 casi in undici categorie distinte. Alcune erano familiari, come le note su una cattiva progettazione o sulla documentazione mancante. Tuttavia, quattro categorie erano interamente nuove e specifiche per il mondo dei test. Queste includevano "test limitati", dove uno sviluppatore ammette che il test controlla solo una piccola parte non rappresentativa del problema; "test saltati", dove un test viene esplicitamente disattivato perché non può essere eseguito nell'ambiente corrente; "in attesa", dove un test attende che uno strumento o un servizio esterno diventi disponibile; e "incertezza", dove lo sviluppatore non è sicuro se il test sia anche corretto. Questa tassonomia ha rivelato che il codice di test porta con sé i propri pesi unici, spesso legati alle sfide specifiche della validazione del comportamento del software piuttosto che alla sua costruzione.

Avendo mappato come si presentano questi debiti, il team si è posto una seconda domanda, più pratica: i computer possono trovarli automaticamente? Hanno testato sette strumenti esistenti progettati per individuare queste note nel codice sorgente regolare. Hanno anche testato una gamma di modelli di intellzione artificiale, inclusi sia modelli open-source che potenti sistemi proprietari di grandi aziende tecnologiche. I risultati sono stati sorprendenti. Gli strumenti esistenti, che si basano sulla ricerca di parole chiave specifiche come "TODO" o "FIXME", hanno ottenuto le prestazioni migliori tra i metodi tradizionali, ma hanno comunque mancato più di un terzo dei debiti effettivi. Erano bravi a essere corretti quando trovavano qualcosa, ma fallivano nel trovare molti dei problemi reali.

I modelli di intelligenza artificiale si sono comportati ancora peggio in modi diversi. I modelli open-source hanno faticato a trovare i debiti, spesso fallendo nel riconoscerli a meno che le note non contenessero parole chiave molto ovvie. Quando trovavano qualcosa, erano frequentemente errati. I modelli proprietari, che sono generalmente considerati più avanzati, hanno mostrato il problema opposto. Hanno trovato quasi tutti i debiti, ma hanno anche segnalato centinaia di commenti innocui come problemi. Erano così ansiosi di trovare problemi da scambiare spiegazioni di routine per ammissioni di fallimento. Alla fine, né gli strumenti tradizionali né i sistemi di IA più avanzati potevano rilevare in modo affidabile questi debiti nel codice di test.

Lo studio conclude che il modo in cui gli sviluppatori scrivono dei problemi nel codice di test è fondamentalmente diverso da come scrivono dei problemi nel codice principale. Le note nei file di test utilizzano spesso un linguaggio specifico per il processo di testing, come menzionare che un test è "disabilitato" o "saltato", che gli strumenti standard e i modelli di IA non riconoscono come segno di debito. I ricercatori hanno scoperto che i metodi attuali non sono ancora pronti a gestire questa complessità. Hanno creato un nuovo dataset e una mappa dettagliata di questi tipi di debito per aiutare i futri ricercatori a costruire strumenti di rilevamento migliori. Fino ad allora, il compito di trovare e correggere questi difetti nascosti nel codice di test rimane un lavoro che richiede l'attenzione umana.