Vantaggi dello Sviluppo Guidato dai Test: Statistiche Chiave & Studi
In questo articolo, analizzo alcune statistiche e studi sullo sviluppo guidato dai test per comprendere come viene applicato, i benefici e le sfide che i team affrontano con questo approccio.
Tradizionalmente, il processo di sviluppo software procede in modo lineare. Tuttavia, negli ultimi decenni, con la crescente popolarità dei sistemi agili (fino all'87% dei team segue un approccio agile o simile), lo sviluppo software ha iniziato ad adottare 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'ambito dello sviluppo software agile.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
In un articolo pubblicato dall'Institute of Electrical and Electronics Engineers, gli autori Yahya Rafique e Vojislav Misic affermano che “Test-Driven Development (TDD) è una delle pratiche fondamentali del processo di sviluppo 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, permangono domande riguardo alle affermazioni sulla produttività e qualità legate al TDD.
Abbiamo impiegato del tempo a raccogliere le statistiche più recenti sul TDD per verificare le affermazioni fatte.
Questo articolo inizia definendo il concetto di TDD e come esso differisce dall'approccio tradizionale. In seguito, analizziamo alcune statistiche che confermano o smentiscono le affermazioni fatte sul TDD.
Che cos'è lo sviluppo guidato dai test?
Lo sviluppo guidato dai test è un approccio in cui si scrive un test prima che il programmatore crei il codice di produzione necessario a soddisfare il test. L'idea di base di questa tecnica è consentire a chi scrive il codice di prendersi del tempo per riflettere su design o requisiti prima di scrivere codice funzionante.
Processo TDD
- Scrivere il test: Nella TDD, tutte le nuove funzionalità iniziano con la scrittura di un test. Il programmatore deve comprendere la specifica e i requisiti della funzione. Per fare questo, sarà necessario consultare le user story e i casi d'uso per capire l'obiettivo del nuovo codice che stanno sviluppando.
- Il test fallisce: Una volta che il programmatore ha scritto il test, lo esegue. Poiché non esiste ancora il codice che lo implementa, il test fallirà. Questo conferma che il framework di test automatico funziona correttamente ed esclude la possibilità che il nuovo test passi sempre perché difettoso.
- Scrivere il codice: Ora il programmatore sa che la funzionalità funziona secondo il design. Scrive quindi il codice che fa passare il test. Il codice potrebbe non essere perfetto, o superare il test in modo eccellente, ma questo non è un problema. Non ci si aspetta che il programmatore scriva codice oltre la funzionalità per cui il test è stato creato.
- Eseguire i test: Sapendo che la funzionalità funziona come progettato, ogni volta che rilasciano nuovo codice, il programmatore può utilizzare un tool di gestione dei test per rieseguire quel test, ottenendo la validazione che il loro aggiornamento più recente non ha compromesso la funzionalità precedente.
- Refactoring del codice: Nella TDD, man mano che la base di codice cresce, è necessario mantenerla pulita continuamente. Considerando che il focus principale del programmatore nelle fasi precedenti era solo scrivere il codice, questa fase assicura efficienza. Permette di migliorare la struttura interna del codice sorgente del programma preservandone le caratteristiche esterne. Questa fase può eliminare duplicazioni e aggiungere nuove funzionalità.
- Ripetere: I passi sopra vengono ripetuti automaticamente per garantire che i cicli TDD coprano tutte le funzionalità.
Differenze tra TDD e sviluppo tradizionale
Per comprendere la TDD, è opportuno determinare come essa si differenzia dagli approcci tradizionali alla programmazione.
La principale differenza è che i metodi tradizionali seguono un processo lineare, mentre la TDD segue un processo ciclico.
I programmatori che utilizzano i metodi di test tradizionali iniziano creando il codice e si concentrano sui test solo alla fine del processo di sviluppo. Al contrario, chi segue il modello TDD parte creando il test e poi sviluppa il codice che soddisfa il test. Questo approccio condivide molti principi con il movimento shift left nel testing del software.
Mentre il programmatore che utilizza l'approccio tradizionale può prestare attenzione alla correttezza del codice, rischia di non individuare tutte le anomalie del codice. Il programmatore che utilizza il metodo TDD lavora sul codice fino a quando non supera il test, attraverso il refactoring del codice stesso. Questo viene fatto fino a quando il codice non risponde alle funzionalità richieste, un processo che probabilmente porta a meno bug.
TDD è più lento o più veloce rispetto allo sviluppo con test tradizionali?
Per quanto riguarda se il TDD renda il processo di programmazione più veloce, esistono statistiche contrastanti provenienti da varie fonti.
Uno studio di caso che ha coinvolto team di ingegneri software di Microsoft e IBM ha concluso che “i team hanno sperimentato un aumento del tempo di sviluppo iniziale del 15-35%” quando hanno utilizzato la tecnica TDD. Tuttavia, lo studio precisa che questi numeri sono “stimati soggettivamente dalla direzione” (Fonte).
Guardando dal punto di vista in cui gli studi di Microsoft e IBM indicano miglioramenti nella qualità, si può sostenere che, a lungo termine, il TDD faccia risparmiare il tempo che sarebbe stato necessario per risolvere eventuali problemi. I team, sia di Microsoft che di IBM, condividono questa visione (Fonte).
Uno studio focalizzato sulle prime percezioni dei professionisti esperti nell’uso del TDD conclude che “dopo aver superato le difficoltà iniziali nel capire da dove partire e come scrivere un test per una funzionalità che ancora non esiste, i partecipanti acquisiscono maggiore fiducia nell’implementazione di nuove funzionalità e nei cambiamenti, grazie all’ampia copertura dei test” (Fonte). Questo sembra suggerire che col tempo le cose migliorino.
Scrivendo per la piattaforma d'informazione 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 che il processo può essere lento all’inizio, ma afferma: “dopo circa 2 anni, è iniziato qualcosa di magico: ho iniziato a scrivere codice più rapidamente con i test unitari rispetto a prima” (Fonte).
Sembra quindi che l’utilizzo del TDD possa rendere le cose più lente inizialmente. Tuttavia, se si guarda da una prospettiva a lungo termine, il tempo risparmiato grazie a un codice di migliore qualità può compensare il tempo perso all’inizio. Inoltre, ci si può aspettare che man mano che i programmatori migliorano con il TDD, diventino più veloci.
Esistono anche molti altri fattori da considerare quando si cerca di misurare il tempo necessario per ottenere un risultato di alta qualità. Per approfondire questo argomento, ascolta l'episodio di Niall Lynch su The QA Lead podcast in cui si parla di come misurare il T2Q (Time To Quality).
Il TDD porta effettivamente a meno bug?
Nella discussione sopra, uno dei principali vantaggi del TDD presentati è che conduce a meno bug. Ma le statistiche cosa dicono?
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 utilizzavano la pratica TDD.” In particolare, i team IBM hanno registrato una riduzione del 40% della densità di difetti e quelli di Microsoft una riduzione tra il 60% e il 90% (Fonte).
Le statistiche sul test driven development confermano che il TDD produce codice di qualità migliore?
Sulla base dei risultati di uno studio presentato al First International Symposium on IEEE del 2007 in Finlandia, Maria Siniaalto e Pekka Abrahamsson riportano che è stato dimostrato che il TDD produce codice di qualità superiore rispetto a quello sviluppato senza TDD (Fonte).
Nel loro articolo, Siniaalto e Abrahamsson citano uno studio condotto in Cina che ha concluso che la TDD migliora il tracciamento dei processi e la stima dei compiti. Lo stesso studio conclude che “la TDD migliora anche il rispetto di pratiche e linee guida coerenti.” Ciò si traduce in una qualità superiore con meno difetti. Inoltre, i team che hanno utilizzato la 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 la loro percezione nell'utilizzo della TDD, riporta la testimonianza di uno sviluppatore che dice: “La TDD mi ha aiutato a migliorare il codice, rendendolo più leggibile.” Un altro partecipante afferma che “la TDD permette una maggiore manutenibilità” (Fonte).
La TDD favorisce un design più semplice?
Boby George e Laurie Williams, entrambi operanti nel Dipartimento di Informatica della North Carolina State University, hanno condotto un esperimento in cui 24 programmatori sono stati suddivisi in due gruppi: uno ha utilizzato la TDD e l'altro l'approccio lineare.
George e Williams riferiscono che tra i partecipanti, “il 92% degli sviluppatori ritiene che la TDD produca codice di qualità superiore, il 79% pensa che la TDD favorisca un design più semplice e il 71% giudica il metodo sensibilmente efficace” (Fonte).
Queste statistiche sul test driven development relative alla qualità indicano fortemente che la TDD porta effettivamente a codice di qualità superiore e a un design più semplice.
In un articolo pubblicato dal portale di apprendimento gratuito Guru99.com, Kanchan Kulkarni afferma: “La 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 ritenuto difficile entrare nella mentalità TDD, mentre il 23% sostiene che la causa sia la mancanza di una fase di progettazione a priori. Sul totale delle risposte, il 40% ritiene difficile adottare la TDD (Fonte).
Queste statistiche sul test driven development riguardanti l’adozione segnalano che la TDD viene percepita come difficile da adottare.
La TDD è sopravvalutata?
In un articolo pubblicato su Medium.com, Tylor Borgeson, che si definisce uno sviluppatore software Full Stack interessato a Machine Learning, AI, Infrastrutture, DevOps e Agile, utilizza il titolo “Test-Driven Development is Overrated.” Tuttavia, il fatto che abbia inserito il titolo tra virgolette mostra che non si tratta di un’affermazione personale.
Borgeson si rivolge poi a chi sostiene che il metodo sia sopravvalutato e lento, affermando che la maggior parte di quelli che hanno questa opinione non ha provato il metodo abbastanza a lungo. Alla fine dell'articolo dice: “Ora continuate a praticare il Test-Driven Development finché non farà più male” (Fonte).
E ora?
Scopri gli approcci QA dagli esperti nel podcast The QA Lead
Iscriviti alla newsletter di The QA Lead per ricevere le nostre ultime guide pratiche e i nuovi episodi del podcast
Unisciti alla lista d’attesa per il forum della community online di The QA Lead dove puoi condividere best practice con altri professionisti del QA e del software testing.
Speriamo di vederti lì!
