Il mio corso di TDD
TL;DR: what my public TDD course is about.
Imparare il TDD
In gennaio terrò il mio primo corso pubblico di TDD. Grazie ad Alberto Brandolini che lo ha organizzato.
La promessa del TDD
Scrivere programmi che funzionano correttamente gia dalla prima volta che vengono messi in produzione. Sentirsi dire dal cliente che i pochi difetti riscontrati si verificano talmente di rado che non vale neanche la pena di correggerli.
Arriva il cliente con una nuova richiesta. Ha cambiato idea di nuovo. Il nuovo requisito coinvolge una serie di nuovi casi speciali. Non è un problema: concordiamo con il cliente alcuni esempi concreti e lo risolviamo. Il nostro codice è malleabile: il nuovo requisito del cliente spesso richiede solo di creare nuove implementazioni di interfacce esistenti; in questi casi il design supporta facilmente l’introduzione del nuovo requisito. In altri casi invece dobbiamo modificare la struttura del codice per poter inserire bene il codice nuovo. Lo facciamo in maniera controllata, a piccoli passi. Il nostro codice è semplice perché è stato sviluppato a partire dai test: la maggior parte delle volte, il codice che abbiamo prodotto era molto più semplice di quello che ci aspettavamo di dover scrivere.
Ti ricordi? Una volta scrivevamo codice per, tipo, una settimana. Poi passavamo una o due settimane a farlo funzionare, debuggando con le scritte sulla console. Ora il debugging non lo facciamo quasi più. Il codice viene pensato, testato, scritto ed integrato nel giro di minuti, non giorni.
Le difficoltà
Non è stato facile. Io ci ho messo anni per cominciare a capire come funziona il TDD. Sono stati anni produttivi: ogni nuovo gradino di comprensione mi ha permesso di scrivere codice migliore. E ogni nuovo gradino diventava un plateau da cui non era facile scorgere quale fosse il prossimo passo.
Mi sono dovuto ricredere su tante cose. Ho imparato a tenere i framework, il sistema operativo, le librerie al loro posto, per essere sicuro di mantenere il controllo della situazione. Non voglio essere alla mercé di quello che un framework può o non può fare, dei suoi bug e delle sue idiosincrasie. Il codice della mia applicazione adesso è separato dal codice che serve a parlare con il framework.
Ho imparato che il design è importante. Carlo Bottiglieri ha detto “Se il design non lo sai fare, il TDD non te lo insegna.” E’ per questo che dopo i primi successi con il TDD, non riuscivo a migliorare. Ho cercato chi potesse insegnarmelo; ho comprato libri di seconda mano perché l’argomento “design” è talmente fuori moda che i libri non li ristampano più. Alcuni libri che pure avevo letto prima, come il famoso libro dei pattern, non mi avevano detto granché. Ora li rileggo e capisco meglio che cosa vogliono dire.
Ho capito che il design è un modo di pensare; Francesco Cirillo ripeteva “E’ semplice ma non è facile”. Ora capisco che l’idea che avevo io di “semplice” era tutta sbagliata. Capisco anche perché molti programmatori confondono il “semplice” con il “facile”, perché anch’io ho vissuto questa confusione. Coesione e accoppiamento adesso hanno un senso; le vedo nel codice.
E non è finita. Continuo a imparare nuove cose, da libri, blog, colleghi e situazioni sul lavoro. E’ bello quando affrontiamo un problema in pair programming, facendo TDD come si deve e quindi scrivendo solo il minimo che serve per fare passare il test, rimuovendo la duplicazione a ogni passo, e otteniamo codice molto più semplice del previsto. Salta fuori che il TDD è una tecnica di design… proprio come dicevano i libri!
Il corso di TDD
Dal 2007 al 2012 ho lavorato in Sourcesense/XPeppers come coach del team Orione. Abbiamo affrontato molti problemi con TDD. Abbiamo insegnato il TDD (con tutti i limiti della nostra comprensione dell’argomento) presso i nostri clienti. Abbiamo fatto un corso pubblico di TDD di un giorno, che ha avuto un discreto successo.
Dall’aprile 2012 sono tornato consulente indipendente. Faccio il coach freelance presso organizzazioni che vogliono migliorare la maniera in cui lavorano con il software.
Il corso di due giorni sul TDD è stato provato più volte presso i nostri clienti, insieme al mio collega coach Antonio Carpentieri. Nel maggio del 2013 sono stato invitato dagli amici di DotNetToscana a fare un corso di TDD di due giorni. Dopo quell’esperienza ho sentito che il corso era pronto per essere presentato al pubblico.
La prospettiva
Qual’è la prospettiva attraverso cui mostro il TDD?
- Il TDD è divertente. È semplice. Cerco sempre il senso del semplice e del divertente nella programmazione. Per questo sono molto sospettoso quando sento parlare di “framework per testare X”. Mi puzza di complicazione. Per iniziare a fare TDD non c’è nemmeno bisogno di xUnit.
- Il TDD è una tecnica di design. Per me non è uno slogan, è una cosa che pratico per davvero. Per questo quando parlo di TDD parlo anche e soprattutto di come fare design.
- Si parte sempre da una user story. Sviluppiamo per realizzare una richiesta del cliente; per questo il primo test spesso è un acceptance test.
- Acceptance test non significa end-to-end test. Sono due concetti ortogonali; un AT può anche essere un test end-to-end, ma spesso non lo è.
- Separa la parte facile da testare da quella difficile da testare. Concentra tutta la logica interessante nella parte facile da testare.
I miei maestri? Ho imparato da Francesco Cirillo e Carlo Bottiglieri. Considero fondamentali il libro di Kent Beck, Test-Driven Development: By Example, il libro di Steve Freeman e Nat Pryce, Growing Object-Oriented Software Guided By Tests. Condivido molte delle cose che scrivono Arlo Belshee e J.B. Rainsberger. Trovo utili i video di Robert Martin e quelli di Piergiuliano Bossi.
In conclusione
Per me il TDD è uno strumento per migliorare. Senza il TDD, ogni programmatore arriva al suo livello naturale di competenza e si ferma lì. Con il TDD, e il design che devi imparare per fare bene TDD, hai un percorso di miglioramento che non finisce mai. Il mio corso può esserti utile se:
- hai provato qualche volta a fare TDD, ma non è rimasto nella tua pratica quotidiana.
- Hai fatto qualche progetto con TDD ma il codice che ne è uscito fuori era un pasticcio.
- Vorresti iniziare a fare TDD ma non sai da dove cominciare.
- Fai correntemente TDD e hai qualche dubbio da sciogliere per passare al prossimo livello.
- Senti sempre parlare di “design” ma non hai mai trovato un libro che te lo spieghi bene.
Se ti riconosci in uno di questi casi, probabilmente posso aiutarti, perché sono stadi da cui sono passato anch’io.