Test Driven Development (TDD)

Il Test Driven Development, abbreviato TDD, è una pratica di sviluppo software molto diffusa nelle metodologie agili e soprattutto in Extreme Programming. Da molti è considerata come una tecnica fondamentale al fine di ottenere software di maggiore qualità.

Come funziona il Test Driven Development

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 -> Design

In 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.

Red

Si parte pensando a una piccola sezione di programma che si vuole sviluppare e al corrispettivo test che deve fallire fino a quando la funzionalità non è stata implementata correttamente.

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.

In alcuni sistemi viene visualizzata una barra rossa per indicare l’errore, in inglese “red”.

Green

Il passo successivo è implementare la funzionalità mancante scrivendo il minimo indispensabile per far superare il test il più velocemente possibile. L’ideale sarebbe intorno alle 5 linee di codice, includendo soltanto ciò che serve.

Quando il test passa, viene di solito visualizzata una barra verde – “green”.

Non preoccuparti se il codice che hai scritto non è perfetto o se pensi che sia migliorabile. Una volta che il test viene eseguito con successo puoi procedere mediante refactoring, modificando la tua implementazione.

Refactor

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.

I vantaggi del Test Driven Development

Oltre ad ottenere il vantaggio di avere test per ogni parte di codice che scriviamo, procedendo in questo modo siamo costretti a pensare a priori come vogliamo che il nostro codice sia utilizzato. TDD incoraggia a programmare in modo strutturato e ci obbliga a rispettare l’incapsulamento (encapsulation).

L’esecuzione dei nostri test  è un processo che può essere automatizzato, così da identificare in maniera tempestiva parti di codice che possono introdurre bug nell’applicazione, in maniera analoga a quanto ogni moderno IDE fa con la sintassi del codice sorgente, riconoscendo errori di sintassi che risulterebbero in una mancata compilazione del nostro codice.

Un altro vantaggio è che grazie al Test Driven Development puoi lavorare tranquillamente senza il timore di rompere parti di programma scritte in precedenza, spendendo meno tempo in attività di debugging. Non dovrai più scrivere regression test, dal momento che ogni componente sensibile del tuo programma ha già una parte di test in grado di segnalarti prontamente eventuali regressioni.

Quindi devo scrivere test sempre e in ogni caso?

La risposta alla domanda è: sì, laddove è possibile! Sarebbe perfetto se tutto il codice che scriviamo avesse un corrispettivo unit test. In realtà è estremamente difficile avere una copertura del 100% del codice. Dipende molto anche dal tipo di applicazione, se si tratta di parti di front-end o back-end – come nel caso di API.

In alcuni tipi di applicazioni, soprattutto in sistemi di una certa grandezza, una copertura del 100%, oltre a essere altamente improbabile non sarebbe nemmeno efficiente dal punto di vista dei costi. Una buona copertura è intorno all’80% del codice sorgente.

Se sei interessato a conoscere la percentuale di copertura di unit test relativa al tuo progetto, puoi trovare diversi strumenti disponibili in rete, a seconda del linguaggio che utilizzi. Per esempio, se usi PHP esiste PHPCoverage; se programmi in Java ti consiglio Cobertura o EMMA.

I limiti del Test Driven Development

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 i più 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.

Leggi anche: Unit, Integration ed End-to-End testing: differenze e implicazioni architetturali

È FINALMENTE DISPONIBILE IL VIDEOCORSO DI AGILE WAY!

CORSO APPROFONDITO SU SCRUM E SULLE METODOLOGIE AGILI

Aggiornato all’ultima versione della guida ufficiale di Scrum!

Più di 3,5 ore di video lezioni su Scrum, ideale per prepararsi a un esame di certificazione PSM I e per comprendere i valori, i principi e le pratiche dei metodi Agili. In questo corso imparerai:

• Origine, nascita e significato delle metodologie Agili
• Differenze tra Scrum e i modelli tradizionali
• Tutte le componenti del framework Scrum, i valori, le pratiche e le metriche
• Come gestire al meglio un progetto e un prodotto con Scrum
• Come mantenere un’attenzione continua al valore generato e al cliente
• Simulatore di esame di certificazione (80 domande)
• Tanto altro…

A SOLI €14,99*

_{* Offerta limitata nel tempo}