Il test-driven development (TDD), in italiano sviluppo guidato dai test, è una tipologia di sviluppo software che mette al primo posto la fase di testing.
Infatti, secondo questa metodologia, il programmatore scrive per prima cosa dei test automatici sulla base della funzionalità richiesta, test che ovviamente falliranno perché la funzionalità ancora manca.
Viene poi sviluppato il codice minimo che consenta il passaggio del test, codice che passa poi attraverso azioni di refactoring. In questo modo lo sviluppo dell'applicazione procede per cicli, guidati dai test, che favoriscono lo sviluppo di codice minimale, di elevata qualità.
Il Test Driven Development consiste nella scrittura dei test prima dell’implementazione vera e propria della funzionalità. Così come suggerisce il nome, lo sviluppo è guidato (driven) dai test e non viceversa.
Se il flusso in un normale ciclo di sviluppo è: Design -> Codice -> Test, in TDD siamo all’opposto:
Test -> Codice -> DesignIn Test Driven Development si parte dalla scrittura dei test considerando l’aspetto funzionale più che l’implementazione vera e propria. Il punto di vista che devi assumere è quello dei metodi pubblici di una classe.
I test non devono essere complessi, ognuno deve svolgere un solo compito, e vanno scritti in maniera incrementale. Una volta presa familiarità con il metodo, ogni incremento Red – Green – Refactor (vedi sotto) non dovrebbe richiedere più di 5-10 minuti.
TDD di solito segue il ciclo "Red-Green-Refactor":
Rosso
Nella fase rossa, ti comporti come se fossi un utente esigente che vuole utilizzare il codice che sta per essere scritto nel modo più semplice possibile. Devi scrivere un test che utilizza un pezzo di codice come se fosse già implementato. Sembra strano e controintuitivo, ma dobbiamo cominciare a scrivere codice a partire dal test, facendolo fallire – dato che non abbiamo ancora scritto l’implementazione della funzionalità stessa.
Verde
In questa fase invece vanno effettivamente implementati i metodi. Non bisogna tenere conto della qualità del codice ma scrivere solo il minimo indispensabile per far superare il test il più velocemente possibile.
Refactoring
Il refactoring è l’ultimo step del nostro processo in TDD e ci consente di trasformare il nostro codice, adattandolo, semplificandolo, snellendolo, rimuovendo duplicati.
Ricordati però che ogni volta che aggiungi una nuova funzionalità devi ripartire dal “red”, per poi ottenere il “green”, e raggiungere in ultima istanza il “refactor”.
Quando lavori con TDD fai attenzione anche a tutti quei test che passano inaspettatamente, così come presti attenzione a tutti quelli che falliscono.
- Favorisce la creazione di codice ottimizzato.
- Aiuta gli sviluppatori ad analizzare e comprendere meglio i requisiti dei clienti e a richiedere chiarezza quando non sono adeguatamente definiti.
- L'aggiunta e il test di nuove funzionalità diventano molto più semplici nelle ultime fasi di sviluppo.
- La copertura dei test nell'ambito del TDD è molto più elevata rispetto ai modelli di sviluppo convenzionali. Questo perché il TDD si concentra sulla creazione di test per ciascuna funzionalità fin dall'inizio.
- Migliora la produttività dello sviluppatore e porta allo sviluppo di una base di codice flessibile e di facile manutenzione.
Come abbiamo visto TDD è in grado di produrre applicazioni di qualità alta, grazie alla diffusione quasi capillare di unit test. Uno dei limiti principali è l’impossibilità di adottare il Test Driven Development su codice già scritto e in produzione – in questo caso si scrivono i soliti e tradizionali unit test. Il motivo è ovvio, dato che TDD prevede la scrittura dei test prima dell’implementazione. Si può comunque provare procedere su parti nuove.
Un’altro aspetto da tenere in considerazione è la difficoltà a entrare nell’ottica TDD. Ci va forse un attimo a capire come funziona e a essere operativi, ma ci va un po’ più tempo per diventare esperti. Appena si inizia a lavorare con Test Driven Development si può avere una sensazione di calo della produttività, che potrebbe scoraggiare e portare a un abbandono.
È inoltre difficile ottenere buoni risultati con TDD se sei l’unico all’interno del tuo team o della tua organizzazione a farne uso. In questo caso rischieresti di trovarti in situazioni ibride che potrebbero, anche qui, portare a un abbandono della tecnica.
Nonostante i limiti, ti consiglio vivamente di prendere familiarità con il Test Driven Development e servirtene in ogni occasione. Se usato correttamente è utile non solo a migliorare il design e la qualità del tuo software, ma può anche contribuire ad aumentare la tua produttività e quella del tuo gruppo di lavoro.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
