Caratteristiche, utilizzo e vantaggi del Test Driven Development (TDD)

Fase di Test

Dopo la fase di coding o sviluppo software vi è la fase di test del software appena creato. In altre parole, una volta che il programma è stato completato o comunque può iniziare a funzionare, occorre verificare che il suo funzionamento sia conforme a tutte le specifiche che erano state stabilite nella fase di analisi. Questo è lo scopo fondamentale della fase di test.
Gli errori che portano al non rispetto delle specifiche sono di solito molto più insidiosi da scoprire rispetto a quelli che vengono trovati durante il debugging. Non sono errori di sintassi, ma errori logici e concettuali, come, per esempio, lo scrivere il segno ‘+’ invece del segno ‘-‘ entro un algoritmo che richieda la sottrazione e non la somma.
La fase di test prevede quindi di verificare il comportamento effettivo del programma rispetto a quello previsto e di segnalare le differenze di comportamento ai programmatori che dovranno procedere alla ricerca e alla eliminazione delle cause di tali differenze.
I modelli di sviluppo software più moderni pongono l’accento sulla fase di test, anteponendola in alcuni casi alla fase di sviluppo (ad esempio il Test Driven Development, TDD) e prevedendo l’esistenza di suite di test eseguite automaticamente durante la build ed il packaging del progetto, allo scopo di ridurre il più possibile il rischio di regressione.

Test Driven Development (TDD)

Spesso la fase di testing è vista come un fastidio da parte degli sviluppatori software, ed ancor di più lo è la necessità di dover scrivere delle classi di test (codice che testa il codice). La tecnica TDD consiste nella stesura del codice a partire dalle classi di test che ne assicurano il buon funzionamento, test unitari (Unit Test) in questo caso. Questo potente approccio garantisce la copertura di test quasi totale (test coverage) del codice scritto e riduce significativamente il rischio che nel codice possano esservi bug.
Una volta individuati uno o più scenari riguardanti il funzionamento ed il comportamento del software che si va a scrivere, questi vengono convertiti in test unitari. Utile in questi casi è il paradigma Given-When-Then. Ad esempio “Dato che (Given) 4 diviso 2 risulta 2, Quando (When) chiamo il metodo dividi, Allora (Then) il metodo restituisce 2” ma anche “Dato che 0 non è un divisore valido, quando chiamo il metodo dividi, allora il metodo mi restituisce un errore”.

Una volta individuati tutti i casi di test si procede secondo questo ciclo, introducendo un caso di test alla volta:

1. Si scrive il codice relativo al caso di test
2. Lo si lancia e lo si lascia fallire
3. Si scrive codice con il solo scopo di far avere esito positivo a tutti i test scritti (compreso quello fallito al punto 2)
4. Si procede al refactoring del codice scritto al fine di eliminare gli smell. Gli smell sono porzioni di codice che potrebbero, col tempo, portarlo a degenerare (esempio metodi lunghi o ripetuti, ricorso a variabili inutili, ecc.).

Un ulteriore beneficio dato da questa procedura è che il codice scritto, essendo scritto in modo incrementale e soggetto a continui refactoring rimane semplice e facilmente comprensibile e manutenibile.