Il TDD viene spesso considerato una pratica per scrivere test. Non è cosi: il TDD è principalmente una pratica per fare design.
Tempo fa, durante lo sviluppo di un'applicazione, mi è capitato di dover scrivere un algoritmo per la schedulazione delle risorse. Non sono un esperto di algoritmi di schedulazione, ho letto un po' di materiale al riguardo, so che esistono metodi più o meno complessi e con più o meno variabili, ma siccome quello che mi serviva era abbastanza semplice ho preferito affrontare il problema per piccoli passi ed eventualmente arrivare ad una soluzione già documentata tramite refactoring del codice. Inutile dire che il TDD ha semplificato ulteriormente lo sviluppo.
Ho raccolto i requisiti del cliente sotto forma di storie, una storia per ogni caso che l'algoritmo doveva risolvere. Ho ordinato le storie per complessità e ho iniziato a scrivere un test.
Il primo test provava a schedulare una risorsa sempre disponibile su un periodo di tempo illimitato e non occupato.
Una volta che questo è diventato verde,sono passato a due risorse, poi a 3 e poi a N.
Poi ho scritto altri test per ridurre il tempo a disposizione e altri ancora che introducevano sovrapposizioni di risorse, fino ad arrivare a test complessi che riproducevano situazioni reali con N risorse, N progetti già schedulati, e poco tempo a disposizione.
In pratica ogni test aggiungeva una variabile in più e complicava un poco le cose, implementavo la nuova funzionalità avendo comunque i vecchi test che verificavano che la nuova feature non rovinasse ciò che era già scritto. Quindi potevo tranquillamente fare refactoring per migliorare continuamente il design che emergeva man mano implementavo nuovi test.
Dopo circa una trentina di test avevo l'algoritmo pronto ma non solo, la correttezza dell'algoritmo era supportata e verificata da una suite di test che considerava tutti i casi emersi durante l'analisi.
Non so se è l'algoritmo migliore che si poteva scrivere, non è sicuramente il più performante ma per i requisiti attuali va benissimo.
Naturalmente dopo la consegna, il cliente ci ha giocato un po' ed ha richiesto alcune modifiche (ma dai? Strano!).
Ma se in genere queste modifiche risultano molto pericolose (soprattutto su problemi di questo tipo che vedono numerose variabili in gioco) avendo a disposizione una serie di test su tutto il codice già scritto aggiungere nuove funzionalità vuol dire semplicemente scrivere altri test o modificare quelli esistenti e una volta implementata la modifica rilanciare tutti i test per verificare che tutto sia ancora verde.
Quindi il vantaggio è doppio: da un lato il TDD mi aiuta a risolvere un problema step-by-step tenendo sempre sotto controllo l'avanzamento verso la soluzione (ogni step mi avvicina al risultato), dall'altro mi permette di introdurre modifiche e migliorie in poco tempo ma soprattutto senza paura di introdurre nuovi bug.
Secondo me impagabile.