Test Driven Development
Pagina 1 di 8
Il Test Driven Development (TDD) è una tecnica non tradizionale per lo sviluppo del software e consiste in una sorta di "sviluppo guidato dai test".
Il TDD è una valida alternativa alla tradizionale tecnica a cascata (waterfall) che prevede analisi, progettazione, scrittura del codice e, solo alla fine, testing e debug.
Il TDD, invece, prevede che la scrittura del codice avvenga mediante dei test secondo un ordine ben preciso:
- si scrive il test prima ancora che esista il codice da testare (se eseguito, ovviamente, il test fallisce);
- si scrive il codice minimo affinchè il test possa essere superato;
- si esegue il refactoring del codice affinchè questo si adegui a standard qualitativi più elevati.
Brevi cenni sorici
Nonostante questa tecnica sembri risalire a molti anni fa, essa è stata formalizzata da Kent Beck solo nel 2003. Di fatto, però, il TDD è fortemente legato al concetto di test-first programming(TFP), paradigma di programmazione dell' extereme programming (XP) formalizzato già nel 1999 e ultimamente molto in voga in ambito industriale.
I requisiti
Il TDD prevede la creazione, da parte dello sviluppatore, di unit test (test di unità) automatizzati prima della scrittura del codice stesso. I test contengono asserti che possono essere sia veri che falsi. Il superamento dei test conferma che il software ha il comportamento desiderato e quindi lo sviluppatore si può dedicare alla rifattorizzazione del codice.
Gli sviluppatori spesso usano framework di test. Nel nostro esempio utilizzeremo il più noto su piattaforma Java, jUnit.
Immaginiamo di dover sviluppare, con la tecnica che andremo ad apprendere, un programma che sia in grado di dirci se una frase è l'anagramma di un'altra.
Un caso di studio
Innanzitutto partiamo dalla definizione di anagramma: un anagramma (dal greco ana-, "indietro", e graphein, "scrivere") è il risultato della permutazione delle lettere di una o più parole compiuta in modo tale da creare altre parole o eventualmente frasi di senso compiuto. Il significato delle parole risultanti non di rado risulta affine al contesto originario, o ad esso completamente opposto, producendo così sorpresa: o con effetti umoristici o, comunque, con interessanti associazioni (es.: attore = teatro, bibliotecario = beato coi libri). Trovate qui una più precisa descrizione.
La nostra speculazione ovviamente si limiterà all'accezione più generica, includendo eventualmente anche le frasi non di senso compiuto. Trascureremo anche la complessità computazionale degli effetti umoristici.
L'approccio
Mettiamo subito in pratica i principi base del Test Driven Development cominciando la nostra speculazione sul dominio applicativo al contrario di come faremmo di solito. Quindi piuttosto che procedere formalizzando la raccolta dei requisiti attraverso una lista di possibili task da implementare, procediamo descrivendo una serie di test che vorremmo che il nostro programma fosse in grado di superare.
La prima domanda da porsi, anche se può sembrare scontata è: cosa è un test e quali sono le sue caratteristiche.
Attingendo dalla letteratura informatica definiremo un test come una prova di correttezza di un determinato asserto.
Un buon test, inoltre, deve essere:
- atomico: quindi di piccola entità e focalizzato su una particolare caratteristica del comportamento desiderato
- isolato: ovvero indipendente da qualsiasi altro test già implementato o da implementare.
