I vantaggi dello sviluppo guidato dai test: statistiche chiave e studi
In questo articolo, analizzo alcune statistiche e studi sullo sviluppo guidato dai test per capire come viene impiegato, i benefici ottenuti e le sfide che i team affrontano con questo approccio.
Tradizionalmente, il processo di sviluppo software procede in modo lineare. Tuttavia, negli ultimi decenni, mentre i sistemi agili stanno diventando più popolari (fino all'87% dei team adotta un approccio agile o simile), lo sviluppo software ha iniziato ad abbracciare metodologie differenti che tengono conto dei requisiti e delle caratteristiche del progetto.
La tecnica dello sviluppo guidato dai test (TDD) è uno dei metodi che ha attirato l'attenzione nell’area dello sviluppo software agile.
Vuoi di più da The CTO Club?
Crea un account gratuito per completare questo articolo e unirti a una comunità di CTO e leader ingegneristici che condividono framework, strumenti e approfondimenti reali per progettare, implementare e scalare tecnologie guidate dall'IA.
Have an account? Log In
In un articolo pubblicato dall'Istituto degli Ingegneri Elettrici ed Elettronici, gli autori Yahya Rafique e Vojislav Misic affermano che “Test-Driven Development (TDD) è una delle pratiche fondamentali nel processo di sviluppo dell’Extreme Programming (XP)” (Fonte).
L’uomo a cui si attribuisce lo sviluppo del TDD avrebbe "dichiarato nel 2003 che il TDD incoraggia design semplici e ispira fiducia" (Fonte). Tuttavia, rimangono domande riguardo le affermazioni sulla produttività e qualità del TDD.
Abbiamo dedicato del tempo a raccogliere le statistiche più recenti sul TDD per verificare le affermazioni fatte a riguardo.
Questo articolo inizia definendo il concetto di TDD e come si differenzia dall'approccio tradizionale. Poi analizziamo alcune statistiche che confermano o confutano le affermazioni sul TDD.
Cos’è lo sviluppo guidato dai test?
Lo sviluppo guidato dai test è un approccio in cui un test viene scritto prima che lo sviluppatore scriva il codice di produzione necessario a soddisfare quel test. L’idea di base di questa tecnica è di permettere all'autore del codice di prendersi il tempo per riflettere sul design o sui requisiti del software prima di scrivere codice funzionale.
Processo TDD
- Scrittura del test: Nel TDD ogni nuova funzionalità inizia con la scrittura di un test. Il programmatore deve comprendere la specifica e i requisiti della funzionalità. Per farlo, dovrà analizzare user story e casi d’uso allo scopo di capire l’obiettivo del nuovo codice che sta sviluppando.
- Il test fallisce: Una volta scritto il test, il programmatore lo esegue. Poiché non esiste ancora il codice che lo implementa, il test fallirà. Questo conferma che il framework di test automatici funziona correttamente e garantisce che il nuovo test non passerà sempre perché difettoso.
- Scrivi il codice: Ora il programmatore sa che la funzionalità funziona come da progettazione. Quindi scrive il codice che soddisfa il test. Il codice potrebbe non essere perfetto, o superare brillantemente il test, ma non è importante. Non ci si aspetta che lo sviluppatore scriva codice oltre la funzionalità che il test è stato creato per verificare.
- Esegui i test: Sapendo che la funzionalità funziona com’è stata progettata, ogni volta che viene rilasciato nuovo codice, il programmatore può usare un tool di gestione dei test per rieseguire quel test e ottenere la conferma che l’aggiornamento più recente non abbia compromesso la funzionalità precedente.
- Refactoring del codice: Nel TDD, man mano che la base di codice cresce, va continuamente ripulita. Dal momento che nelle fasi precedenti il focus principale del programmatore è stato semplicemente scrivere il codice, questa fase serve ad aumentare l’efficienza. Permette di migliorare la struttura interna del codice sorgente del programma preservando le caratteristiche esterne. Questa fase può eliminare duplicazioni e aggiungere nuove funzionalità.
- Ripeti: I passaggi precedenti vengono ripetuti automaticamente per garantire che i cicli TDD coprano tutte le funzionalità.
Differenze tra TDD e sviluppo tradizionale
Per comprendere il TDD, è opportuno identificare come si differenzia dagli approcci tradizionali di programmazione.
La principale differenza è che i metodi tradizionali seguono un processo lineare, mentre il TDD si svolge secondo un processo ciclico.
I programmatori che utilizzano i metodi tradizionali di test iniziano creando il codice e si concentrano sul test solo alla fine del processo di sviluppo. Al contrario, chi segue il modello TDD inizia creando il test e poi sviluppa il codice che soddisfa quel test. Questo approccio condivide molti principi con il movimento "shift left" nel test del software.
Mentre il programmatore che usa l'approccio tradizionale può prestare attenzione alla correttezza del codice, corre il rischio di non riuscire a individuare tutti gli errori del codice. Il programmatore che utilizza il metodo TDD lavora sul codice fino a quando non supera il test, attraverso la rifattorizzazione del codice. Questo viene fatto fino a quando il codice soddisfa la funzionalità, un processo che probabilmente porta a meno bug.
Il TDD è più lento o più veloce rispetto allo sviluppo dei test tradizionali?
Per quanto riguarda se il TDD renda il processo di programmazione più rapido, esistono statistiche contrastanti provenienti da diverse fonti.
Uno studio di caso che ha coinvolto team di ingegneri software di Microsoft e IBM ha concluso che le “squadre hanno sperimentato un aumento del tempo di sviluppo iniziale tra il 15% e il 35%” quando hanno utilizzato la tecnica TDD. Tuttavia, lo studio nota che questi sono numeri “stimati soggettivamente dalla direzione” (Fonte).
Se si considera che, secondo gli studi Microsoft e IBM, si sono registrati miglioramenti nella qualità, si può sostenere che, nel lungo termine, il TDD fa risparmiare il tempo che sarebbe stato necessario per correggere i problemi. I team di Microsoft e IBM sono stati d'accordo con questa visione (Fonte).
Uno studio che si concentra sulle percezioni iniziali dei professionisti esperti nell’utilizzo del TDD conclude che “dopo aver superato le difficoltà iniziali nel capire da dove cominciare e come creare un test per una funzionalità che ancora non esiste, i partecipanti acquisiscono maggiore fiducia nell’implementare nuove funzionalità e apportare modifiche grazie all’ampia copertura dei test” (Fonte). Questo sembra suggerire che le cose migliorino con il tempo.
Scrivendo per la piattaforma di pubblicazione online Medium.com, il programmatore e autore di “Composing Software” e “Programming JavaScript Applications”, Erick Elliot si concentra su come il TDD abbia cambiato la sua vita. Elliot concorda sul fatto che il processo possa essere lento all’inizio, ma afferma: “da qualche parte intorno ai 2 anni è iniziato a succedere qualcosa di magico: ho iniziato a programmare più velocemente con i test unitari rispetto a quanto abbia mai fatto senza” (Fonte).
Sembra che l’uso del TDD possa inizialmente rallentare le cose. Tuttavia, se si guarda in una prospettiva di lungo periodo, il tempo risparmiato grazie a un codice di migliore qualità può compensare il tempo perso all’inizio. Inoltre, è prevedibile che, man mano che i programmatori acquisiscono maggiore esperienza con il TDD, siano in grado di lavorare più velocemente.
Ci sono anche molti altri fattori da considerare quando si cerca di misurare il tempo necessario per ottenere un risultato di alta qualità. Per approfondire questo aspetto, ascolta l’episodio di Niall Lynch su The QA Lead podcast riguardo la misurazione del T2Q (Time To Quality).
Il TDD porta davvero a meno bug?
Nella discussione precedente, uno dei principali vantaggi presentati del TDD è che porta a meno bug. Ma le statistiche confermano questa affermazione?
Gli stessi studi che hanno coinvolto i team di ingegneri di Microsoft e IBM hanno concluso che “la densità di difetti prima del rilascio dei quattro prodotti è diminuita tra il 40% e il 90% rispetto a progetti simili che non hanno utilizzato la pratica TDD.” In particolare, i team di IBM hanno registrato un calo del 40% nella densità dei difetti, mentre quelli di Microsoft hanno registrato una diminuzione del 60-90% (Fonte).
Le statistiche sul Test Driven Development supportano la conclusione che il TDD produce un codice di qualità migliore?
Sulla base dei risultati di uno studio presentato al Primo Simposio Internazionale IEEE del 2007 in Finlandia, Maria Siniaalto e Pekka Abrahamsson segnalano che è stato dimostrato che il TDD produce un codice di migliore qualità rispetto al software sviluppato senza questa pratica (Fonte).
Nel loro articolo, Siniaalto e Abrahamsson citano uno studio condotto in Cina che ha concluso che il TDD migliora il tracciamento dei processi e la stima delle attività. Lo stesso studio conclude che “il TDD favorisce anche il rispetto di pratiche e linee guida coerenti.” Questo si traduce in una migliore qualità con meno difetti. Inoltre, i team che hanno utilizzato il TDD sono stati in grado di correggere i loro difetti più rapidamente (Fonte).
Uno studio condotto tra sviluppatori, con circa dieci anni di esperienza professionale (in media), per indagare le loro percezioni nell'utilizzo del TDD, riporta la testimonianza di uno sviluppatore che afferma: “Il TDD mi ha aiutato a migliorare il codice, rendendolo più leggibile.” Un altro partecipante riferisce che “il TDD consente una maggiore manutenibilità” (Fonte).
Il TDD Promuove un Design Più Semplice?
Boby George e Laurie Williams, entrambi impegnati nel Dipartimento di Informatica della North Carolina State University, hanno condotto un esperimento in cui 24 programmatori sono stati divisi in due gruppi: uno ha utilizzato il TDD e l'altro un approccio lineare.
George e Williams riportano che tra i partecipanti, “il 92% degli sviluppatori riteneva che il TDD produca codice di qualità superiore, il 79% pensava che il TDD favorisca un design più semplice e il 71% riteneva che l'approccio fosse visibilmente efficace” (Fonte).
Queste statistiche sul test driven development riguardanti la qualità forniscono una forte indicazione che il TDD porta effettivamente a codice di qualità superiore e design più semplice.
In un articolo pubblicato dal portale di apprendimento gratuito Guru99.com, Kanchan Kulkarni afferma: “Il TDD rende il codice più semplice e chiaro. Permette allo sviluppatore di mantenere meno documentazione” (Fonte).
È Facile Adottare il Design TDD?
Dall'esperimento di George e Williams, il 56% degli sviluppatori professionisti ha dichiarato che è stato difficile entrare nell'ottica del TDD, mentre il 23% sostiene che la mancanza di una fase di progettazione preventiva è la causa di questa difficoltà. Sul totale delle risposte, il 40% riteneva difficile adottare il TDD (Fonte).
Queste statistiche sul test driven development relative all'adozione indicano che il TDD viene percepito come difficile da adottare.
Il TDD è Sopravvalutato?
In un articolo pubblicato su Medium.com, Tylor Borgeson, che si definisce uno sviluppatore software full stack interessato a Machine Learning, AI, Infrastructure, DevOps e Agile, utilizza il titolo “Test-Driven Development is Overrated.” Tuttavia, il fatto che abbia posto il titolo tra virgolette dimostra che non si tratta di un'affermazione che vuole sostenere.
Borgeson si rivolge poi a coloro che affermano che il metodo sia sopravvalutato e lento, dicendo che la maggior parte di queste persone non l'ha usato abbastanza a lungo. Concludendo il suo articolo, dice: “Ora esercitati con il Test-Driven Development finché non ti farà più male” (Fonte).
Cosa Succede Ora?
Scopri gli approcci di QA dagli esperti nel podcast The QA Lead
Iscriviti alla newsletter di The QA Lead per ricevere le nostre ultime guide pratiche ed episodi del podcast
Unisciti alla lista d'attesa per il forum online della community The QA Lead dove puoi condividere best practice con altri professionisti del QA e del software testing.
Spero di vederti lì!
