Se c’è una cosa che Martin Fowler e Kent Beck hanno in comune, oltre alla loro indiscutibile genialità nel mondo della programmazione, è la loro passione per un approccio rivoluzionario alla scrittura del codice: il Test-Driven Development, o TDD, è sicuramente una delle pratiche che li accomuna e che entrambi hanno sempre sostenuto.
Viviamo in un mondo dove i mostri sacri della programmazione ci sussurrano all’orecchio quelle che si sono dimostrate le migliori pratiche per sviluppare software durante gli anni, ed è una fortuna incommensurabile.
Come ho già scritto in passato su questo blog, non si può essere agili senza eccellenza tecnica: per supportare i business nell’essere veloci a rispondere, dobbiamo noi per primi essere veloci a mandare codice in produzione.
Tra le varie pratiche che abilitano l’eccellenza tecnica c’è sicuramente il TDD, che ha un vantaggio rispetto alle altre: è individuale, ovvero possiamo introdurla nel nostro lavoro senza che il resto del team debba allinearsi a noi o concordare – e questo la rende la pratica più semplice da introdurre per migliorare il nostro lavoro quotidiano.
Cos’è il TDD
Il TDD è una metodologia di sviluppo che si basa sul principio fondamentale di scrivere test prima di scrivere il codice di produzione, ma la defizione migliore ce la da Martin Fowler nel suo articolo sul tema:
Test-Driven Development (TDD) is a technique for building software that guides software development by writing tests.
Martin Fowler
Il TDD non ci chiede semplicemente di scrivere prima i test, anzi – quello è solo un pezzo del puzzle. Lo scopo del TDD è guidare le scelte che prendiamo nel software tramite la scrittura dei test, per ottenere l’obiettivo finale del TDD: “clean code that works”, ovvero “codice pulito che funziona”.
Per ottenere questo obiettivo, il TDD ci suggerisce di seguire un ciclo di sviluppo semplice e chiaro, noto come “Red-Green-Refactor“: si inizia con la scrittura di un test che fallisce (rosso), seguito dall’implementazione del codice per far passare il test (verde), e infine dalla rifattorizzazione del codice per renderlo più pulito e manutenibile (refactor).
Ma cosa vuol dire tutto ciò nella pratica? Per prima cosa, vediamo più nel dettaglio il ciclo di sviluppo TDD canonico descritto da Kent Beck, con l’aggiunta di qualche pezzo fondamentale che troppo spesso ci si dimentica:
- Scrivi una lista degli scenari di test che vuoi coprire per il nuovo comportamento da aggiungere al tuo software
- Prendi un elemento dalla lista e trasformalo in un test, che fallirà perchè quel comportamento ancora non esiste
- Cambia il codice di produzione per implementare quel comportamento, in modo che il nuovo test diventi verde (e i precedenti lo rimangano)
- Durante il processo potresti scoprire nuovi scenari di test che vuoi coprire: se succede, aggiungili alla lista del punto 1
- Migliora il tuo design facendo un pò di refactoring, assicurandoti che i test rimangano verdi
- Ripeti dal punto 2 finchè la lista non è vuota
Alcune riflessioni su questo processo:
- la lista di scenari di test serve a rendere esplicite due informazioni fondamentali:
- il comportamento atteso dal nostro software (quando i test sono versi, il comportamento è stato ottenuto)
- il progresso del nostro lavoro (quando la lista è vuota, abbiamo finito)
- il processo guida le nostre scelte di design perchè scriviamo il test prima del codice, quindi invocheremo classi e metodi che ancora non esistono, decidendone il nome e la struttura durante la scrittura dei test
Infine, uno zoom ulteriore sul ciclo RED-GREEN-REFACTOR in relazione all’obiettivo del TDD, che abbiamo detto essere “codice pulito che funziona”: ottenere questo risultato in un unico flusso di scrittura di codice è molto difficile; il ciclo TDD ci vuole portare a quest’obiettivo dividendolo in step più piccoli, in modo che sia semplice:
- nello step rosso, scriviamo un codice che non funziona
- nello step verde, scriviamo un “codice che funziona”: non ci preoccupa il design, ci va bene anche una soluzione non bella purchè funzioni, lo scopo è rendere il test verde più velocemente possibile perchè il test verde ci da sicurezza psicologica e senso di progresso
- nello step di refactor, infine, ci occupiamo solo ed esclusivamente di rendere il nostro codice “pulito” andandone a migliorare e ripulire il design; nel farlo, i test devono rimanere verdi in modo da assicurarci che il codice continui a funzionare
Grazie a questo approccio, otteniamo con molta meno fatica cognitiva l’agognato risultato di “codice pulito che funziona”.
Infine, è importante riflettere sul fatto che un ciclo TDD dovrebbe ripetersi ogni x secondi, quindi meno di un minuto: se scrivere un test o implementare un test rosso ci occupano svariati minuti, dovremmo fare un passo indietro e scrivere un test diverso, più piccolo, che ci permetta di fare progresso velocemente.
Questo approccio risulta fondamentale sopratutto quando il problema che abbiamo davanti ci è poco familiare e dobbiamo “scoprire” la soluzione, perchè più i nostri step sono piccoli più il TDD ci guiderà verso una soluzione – al contrario, quando abbiamo già chiara una implementazione che ci soddisfa, possiamo fare step un poco più lunghi con sicurezza.
L’impatto del TDD nella mia carriera
Personalmente, il TDD ha avuto un impatto enorme sulla mia carriera di sviluppatore software. Innanzitutto, ha migliorato notevolmente la qualità del mio lavoro quotidiano. Scrivendo test prima di implementare il codice, sono in grado di identificare e correggere gli errori in modo tempestivo, riducendo così il rischio di bug e migliorando complessivamente l’affidabilità del mio software.
Inoltre, il TDD ha anche migliorato la qualità dei miei test stessi. Essendo costretto a scrivere test che coprono tutti gli aspetti del mio codice, ho imparato a scrivere test più robusti e significativi, garantendo una maggiore copertura dei casi edge e una maggiore sicurezza nei miei test.
Uno degli aspetti più importanti del TDD è la facilità di cambiare e mantenere il codice. Poiché il codice è scritto per essere testabile fin dall’inizio, è molto più facile apportare modifiche e aggiornamenti in futuro senza temere di rompere il software esistente.
Infine, il TDD ha portato maggiore sicurezza, produttività ed efficacia nel mio lavoro. Con un set completo di test a supporto del mio codice, ho la tranquillità di sapere che il mio software funziona come previsto e posso concentrarmi su nuove funzionalità e miglioramenti senza preoccuparmi di regressioni o bug inaspettati.
I due feedback fondamentali sul fatto che il TDD abbiamo rivoluzionato la mia carriera (in positivo) sono stati due:
- in primis, il tempo che investo sugli imprevisti come bug, defects e problemi in produzione legati a codice scritto da me si è ridotto drasticamente, quasi a zero in alcuni casi: il codice che scrivo è affidabile e fa quello che deve fare
- in secondo luogo, quando sono stato Tech Lead di un team e avevo quindi meno tempo da dedicare al codice, essere in grado di utilizzare il ciclo TDD, che ti permette di fare progresso anche solo in un minuto (perchè un ciclo TDD deve durare idealmente pochi secondi), mi ha permesso di sfruttare al meglio tutti i momenti liberi che avevo per programmare, anche quando erano solo 10/15 minuti
Non posso che suggerire a tutti di avvicinarsi a questa pratica, perchè ti permette di ottenere un risultato di qualità elevata nel codice con uno sforzo nettamente minore rispetto a quello necessario per ottenere lo stesso risultato senza TDD.
Come imparare il TDD
Se sei interessato a imparare il TDD, ci sono diverse risorse disponibili. Il migliore punto di partenza è il libro di Kent Beck, “Test-Driven Development by Example“, che offre una guida pratica e dettagliata alla pratica del TDD. Questo libro è così ben scritto che è utile persino rileggerlo di tanto in tanto anche per chi già conosce la pratica, perchè c’è sempre qualcosa di nuovo da scoprire.
Aggiungo però un secondo libro, quello che ha avuto maggiore impatto sulla mia carriera: “Agile Technical Practices Distilled“, un libro che fornisce una panoramica approfondita delle pratiche tecniche agili, inclusa una sezione dedicata al TDD ad inizio libro davvero efficace e ben scritta. È un libro scritto con l’intento di insegnare, e ottiene a pieno il suo scopo.
Oltre alla lettura, è importante praticare il TDD attraverso esercizi pratici, noti come “katas”. I katas sono esercizi di programmazione che ti sfidano a risolvere problemi specifici utilizzando il TDD. Praticare regolarmente i katas ti aiuterà a sviluppare e rafforzare le tue abilità di TDD nel tempo. Comincia da kata semplici, come i classici FizzBuzz e Leap Year, in modo da poterti concentrare sulla pratica specifica, e poi alza il livello a mano a mano che diventi confidente.
Ti suggerisco anche i video di Emily Bache, una technical coach focalizzata sulle pratiche agili che fa video che servono proprio a fare learning su questi temi: in questo video, ad esempio, Emily svolge il kata “12 days of XMas” in TDD, passo dopo passo, spiegando la pratica in modo eccezionale.
In conclusione, il TDD è una pratica potente che può portare enormi benefici alla tua carriera di sviluppatore software. Imparare il TDD richiede impegno e pratica costante, ma i risultati ne valgono sicuramente la pena. Inizia oggi stesso il tuo viaggio nel mondo del Test-Driven Development e scopri il potenziale che questa pratica ha da offrire.
Se questo articolo ti è piaciuto, sappi che è parte di una serie mensile a tema Agile, il che significa che puoi recuperare i precedenti e che ne arriveranno altri nei prossimi mesi! In più, se ti piace il mio stile, dai un occhiata a Learn Agile Practices, il mio ecosistema di contenuti online nei quali parlo di pratiche e metodologie Agile come TDD, CI, CD e molto altro a tema programmazione.
Scopri tutto su learnagilepractices.com e seguimi su LinkedIn!
