Cos’è il Test Driven Development, approcci e vantaggi

Test Driven Development (TDD) è un approccio di sviluppo software in cui vengono sviluppati casi di test per specificare e convalidare ciò che il codice farà.

Praticamente i casi di test per ciascuna funzionalità vengono creati e testati prima che il software venga distribuito, e se il test fallisce, il nuovo codice viene scritto (o riscritto o corretto) per superare il test e rendere il codice semplice e privo di bug.

Lo sviluppo guidato dai test (TDD) inizia con la progettazione e lo sviluppo di test per ogni piccola funzionalità di un’applicazione. Il framework TDD indica agli sviluppatori di scrivere nuovo codice solo se un test automatizzato ha avuto esito negativo. Questo approccio evita la duplicazione del codice. Il modulo completo TDD è lo sviluppo guidato dai test.

Lo sviluppo guidato dai test (TDD) è nato come parte di un paradigma di progettazione software più ampio noto come Extreme Programming (XP), che fa parte della metodologia di sviluppo software Agile.

Il semplice concetto di TDD è scrivere e correggere i test falliti prima di scrivere nuovo codice (prima dello sviluppo). Questo aiuta a evitare la duplicazione del codice mentre scriviamo una piccola quantità di codice alla volta per superare i test. (I test non sono altro che condizioni di requisiti che dobbiamo testare per soddisfarli).

Lo sviluppo basato su test è un processo di sviluppo ed esecuzione di test automatizzati prima dello sviluppo effettivo dell’applicazione. Quindi, TDD a volte è anche chiamato Test First Development.

Fasi dell’approccio TDD

Prima che venga scritto qualsiasi nuovo codice, il programmatore deve prima creare uno unit test in errore. Quindi, il programmatore – o coppia, o mob – crea il codice appena sufficiente per soddisfare tale requisito. Una volta superato il test, il programmatore può eseguire il refactoring del progetto, apportando miglioramenti senza modificare il comportamento.

Mentre TDD si concentra sulle interazioni del programmatore a livello di unità, ci sono altri metodi popolari, come lo sviluppo guidato dai test di accettazione (ATDD) o lo sviluppo guidato dal comportamento (BDD), che si concentrano su test che possono essere compresi dai clienti.

Questi metodi comportano la creazione di esempi concreti come test in collaborazione tra lo staff tecnico e il cliente prima della creazione del codice e quindi l’esecuzione dei test dopo la creazione del codice per dimostrare che il codice è implementato. Avere i test noti in anticipo migliora la qualità della prima volta. ATDD e BDD richiedono che sviluppatori, tester e il lato aziendale collaborino per immaginare e discutere il software e le sue implicazioni prima che il codice venga creato.

Vantaggi del TDD

Lo sviluppo basato su test può produrre applicazioni di alta qualità in meno tempo di quanto sia possibile con metodi precedenti. La corretta implementazione di TDD richiede agli sviluppatori e ai tester di anticipare con precisione come l’applicazione e le sue funzionalità verranno utilizzate nel mondo reale.

TDD crea una suite di test di regressione come effetto collaterale che può ridurre al minimo i test manuali umani, trovando i problemi in anticipo, portando a soluzioni più rapide. La natura metodica di TDD garantisce una copertura e una qualità per la prima volta molto più elevate rispetto ai classici cicli di codice a fasi > test > correzione > ripetizione del test. Poiché i test vengono condotti fin dall’inizio del ciclo di progettazione, il tempo e il denaro spesi per il debug nelle fasi successive sono ridotti al minimo.

Benefici attesi:

• riduzioni significative dei tassi di difetti, al costo di un moderato aumento dello sforzo di sviluppo iniziale
• i costi generali sono più che compensati da una riduzione dello sforzo nelle fasi finali dei progetti
• TDD porta a migliori qualità di progettazione nel codice e, più in generale, a un più alto grado di qualità “interna” o tecnica, ad esempio migliorando le metriche di coesione e accoppiamento

Svantaggi del TDD

Il TDD richiede una notevole abilità per avere successo, soprattutto a livello di unità. Molti sistemi legacy semplicemente non vengono creati pensando ai test unitari, rendendo impossibile l’isolamento dei componenti per il test.

Inoltre, molti programmatori non hanno le capacità per isolare e creare codice pulito. Tutti i membri del team devono creare e mantenere i test unitari, altrimenti diventeranno rapidamente obsoleti. E un’organizzazione che guarda al TDD dovrà investire tempo, rallentare un po’ ora per andare più veloce in seguito.

Infine, come con qualsiasi metodo, i risultati finali di TDD sono buoni solo quanto i test che sono stati utilizzati, l’accuratezza con cui sono stati eseguiti e la misura in cui imitano le condizioni incontrate dagli utenti del prodotto finale.

Errori comuni:

• dimenticando di eseguire frequentemente i test
• scrivere troppi test contemporaneamente
• scrivere test troppo grandi o grossolani
• scrivere test eccessivamente banali, ad esempio omettendo asserzioni
• scrivere test per codice banale
• adozione parziale: solo pochi sviluppatori di un gruppo di lavoro utilizzano TDD
• scarsa manutenzione della suite di test, che più comunemente porta a una suite di test con un tempo di esecuzione proibitivo
• suite di test abbandonata (ovvero raramente o mai eseguita) – a volte a causa di una scarsa manutenzione, a volte a causa del turnover del team

Filosofia del TDD

TDD consente al programmatore di fare piccoli passi durante la scrittura del software. Il test viene scritto prima di testare la funzionalità e garantisce che l’applicazione sia adatta alla testabilità. Il test su una piccola quantità di codice viene eseguito per intercettare gli errori che si verificano nel codice testato. Quindi la funzionalità è implementata. Questo è indicato come “red green refactor” dove rosso significa fallimento e verde mostra un passaggio. Questi passaggi vengono poi ripetuti. Il primo obiettivo di un programmatore è concentrarsi sul compito da svolgere e superarlo.

Le diverse fasi coinvolte in un ciclo di sviluppo basato su test sono:

• Aggiungi un test: ogni nuova funzionalità in TDD inizia con un test che deve fallire poiché viene messo in atto prima che qualsiasi funzionalità venga implementata. Il requisito essenziale per scrivere un test prima dell’implementazione della funzionalità è una chiara comprensione del requisito da parte dello sviluppatore. Ciò si ottiene attraverso storie utente e casi d’uso. Quindi uno sviluppatore comprende il requisito prima di scrivere il codice del programma.
• Esegui tutti i test e controlla se il nuovo codice fallisce: questo garantisce il corretto funzionamento del test harness e che il nuovo test non passi per errore senza alcun nuovo codice. Questo passaggio verifica anche il test ed elimina la possibilità che il nuovo test venga sempre superato.
• Scrivi codice: il passaggio successivo che segue è la scrittura del codice che cancella il test. Il nuovo codice non è perfetto ma viene successivamente modificato secondo i requisiti. È progettato semplicemente per i test e non racchiude altre funzionalità.
• Eseguire test automatizzati: se ogni caso di test prodotto supera facilmente il test, significa che il codice soddisfa tutte le specifiche richieste. Quindi può essere avviata la fase finale del ciclo.
• Codice di refactoring: è simile alla rimozione della duplicazione. Un refactoring non danneggia alcuna funzionalità esistente e aiuta a rimuovere la duplicazione tra i codici di produzione e di test. Il codice è ora pulito come richiesto.
• Ripeti: Il ciclo si ripete come nei casi precedenti con un nuovo test. Il requisito essenziale è che la dimensione dei passaggi sia ridotta, con circa 1-10 modifiche tra ogni esecuzione del test. Se il nuovo codice non soddisfa un nuovo test, il programmatore dovrebbe eseguire ulteriori debug. L’integrazione continua fornisce punti di controllo reversibili.

Ercole Palmeri