Test driven development

Il test-driven development (abbreviato in TDD), in italiano sviluppo guidato dai test o sviluppo guidato dalle verifiche è un modello di sviluppo del software basato su test automatici. Il modello prevede che lo sviluppo avvenga attraverso la ripetizione di un breve ciclo in tre fasi. Nella prima fase (detta "fase rossa"), il programmatore scrive un test automatico per la nuova funzione da sviluppare, che deve fallire in quanto la funzione non è stata ancora realizzata. Nella seconda fase (detta "fase verde"), il programmatore sviluppa la quantità minima di codice necessaria per passare il test. Nella terza fase (detta "fase grigia" o di refactoring), il programmatore esegue il refactoring del codice per adeguarlo a determinati standard di qualità. L'invenzione del metodo (o la sua riscoperta) si deve a Kent Beck, uno dei padri dell'extreme programming (XP) e dello metodologie agili. Il TDD è una delle 12 regole base dell'XP ma viene anche usato indipendentemente da questa metodologia; la sua applicazione è anche parte fondamentale dello sviluppo agile del software.

I cicli TDD

Rappresentazione tramite flowchart del ciclo TDD

Il TDD si articola in brevi cicli che constano di tre fasi principali. La descrizione originale dei cicli TDD data da Kent Beck nel libro Test-Driven Development by Example è quella usata universalmente come riferimento:

Fase rossa

Nel TDD, lo sviluppo di una nuova funzionalità comincia sempre con la stesura di un test automatico volto a validare quella funzionalità, ovvero verificare se il software la esibisce. Poiché l'implementazione non esiste ancora, la stesura del test è un'attività creativa, in quanto il programmatore deve stabilire in quale forma la funzionalità verrà esibita dal software e comprenderne e definirne i dettagli. Perché il test sia completo, deve essere eseguibile e, quando viene eseguito, produrre un esito negativo. In molti contesti, questo implica che debba essere realizzato uno "stub" minimale del codice da testare, necessario per garantire la compilabilità e l'eseguibilità del test. Una volta che il nuovo test è completo e può essere eseguito, dovrebbe fallire. La fase rossa si conclude quando c'è un nuovo test che può essere eseguito e fallisce.

Fase verde

Nella fase successiva, il programmatore deve scrivere la quantità minima di codice necessaria per passare il test che fallisce. Non è richiesto che il codice scritto sia di buona qualità, elegante, o generale; l'unico obiettivo esplicito è che funzioni, ovvero passi il test. In effetti, è esplicitamente vietato dalla pratica del TDD lo sviluppo di parti di codice non strettamente finalizzate al superamento del test che fallisce. Quando il codice è pronto, il programmatore lancia nuovamente tutti i test disponibili sul software modificato (non solo quello che precedentemente falliva). In questo modo, il programmatore ha modo di rendersi conto immediatamente se la nuova implementazione ha causato fallimenti di test preesistenti, ovvero ha causato regression nel codice. La fase verde termina quando tutti i test sono "verdi" (ovvero vengono passati con successo).

Refactoring

Quando il software passa tutti i test, il programmatore dedica una certa quantità di tempo a farne refactoring, ovvero a migliorarne la struttura attraverso un procedimento basato su piccole modifiche controllate volte a eliminare o ridurre difetti oggettivamente riconoscibili nella struttura interna del codice. Esempi tipici di azioni di refactoring includono la scelta di identificatori più espressivi, eliminazione di codice duplicato, semplificazione e razionalizzazione dell'architettura del sorgente (p.es. in termini della sua organizzazione in classi), e così via. La letteratura sul TDD fornisce numerose linee guida sia specifiche che generali sul modo corretto di fare refactoring In ogni caso, l'obiettivo del refactoring non è quello di ottenere del codice "perfetto", ma solo di migliorarne la struttura, secondo la cosiddetta "regola dei Boy Scout": "lascia l'area dove ti sei accampato più pulita di come l'hai trovata". Dopo ciascuna azione di refactoring, i test automatici vengono nuovamente eseguiti per accertarsi che le modifiche eseguite non abbiano introdotto errori.

Vantaggi

Tali test permettono di individuare con precisione le specifiche del codice, e quindi il suo comportamento in base alle situazioni a cui sarà sottoposto. Ciò facilita la produzione di un codice funzionante in qualunque circostanza, più pulito e più affidabile.

Scrivendo i test prima del codice, si utilizza il programma prima ancora che venga realizzato. Ci si assicura, inoltre, che il codice prodotto è testabile singolarmente. È dunque obbligatorio avere una visione precisa del modo in cui verrà utilizzato il programma prima ancora d'essere implementato. Così facendo si evitano errori concettuali durante la realizzazione dell'implementazione, senza che si siano definiti gli obiettivi. Inoltre, i test consentono agli sviluppatori di avere maggior confidenza durante il refactoring del codice, in quanto già sanno che i test funzioneranno quando richiesto; pertanto, possono permettersi di effettuare cambiamenti radicali di design, stando certi che alla fine otterranno un programma che si comporterà sempre alla stessa maniera (essendo i test sempre verificati).

L'uso del Test Driven Development permette non solo di costruire il programma assieme ad una serie di test di regressione automatizzabili, ma anche di stimare in maniera più precisa lo stato d'avanzamento dello sviluppo di un progetto.

Voci correlate

• Extreme Programming
• Behavior-driven development
• Unit test
• Automazione del collaudo del software
• You Aren't Gonna Need It

Collegamenti esterni

• (EN) Introduction to Test Driven Development (TDD)
• (EN) Test Driven Development