Una delle pratiche più invasive di extreme programming oltre al pair programming è il TDD (Test Driven Development) ed è anche la più difficile da padroneggiare.
In questo post cercherò di analizzare i motivi, fornendo alcuni spunti su come superare le difficoltà.
Le cose più difficili da accettare soprattutto se si ha già una certa esperienza è il fare emergenere il design dai test.
Questo implica di non anticipare eventuali feature successive o test successivi e scrivere il codice minimo indispensabile per fare passare il test appena scritto. Nella fase di refactoring poi si toglieranno tutti gli smell introdotti a partire dal più importante che è la duplicazione.
Quindi non basta scrivere i test prima, magari solo per realizzare un'idea di design che ho già deciso, ma significa sorprendersi del risultato ottenuto.
Una grossa difficoltà è capire quali test scrivere all'inizio e quindi occorre partire molto lentamente, facendo piccoli passi tra un test e il successivo in modo da familiarizzare con la tecnica.
Spesso nell'affrontare il design in questa maniera ci si accorge di avere delle carenze nei concetti di OOP oppure nel riconoscere gli smell e quindi è importante studiare molto bene questi argomenti prima di iniziare.
Bisogna accettare anche il fatto che nel percorso dell'apprendimento si possa sbagliare e il dover rifare la stessa cosa più volte fino ad arrivare ad un risultato soddisfacente.
E' possibile che per ottenere una barra verde del test appena codificato si debba scrivere molto codice, questo è un segno che si è fatto un passo troppo lungo.
Una buona soluzione potrebbe essere quella di revertare il codice e riflettere su come fare un passo più piccolo per arrivare al risultato. Ricordiamoci inoltre di integrare dopo ogni refactoring successivo ad una barra verde per rendere l'operazione più veloce ed indolore possibile.
La disciplina è un alleato potente perché, soprattutto all'inizio, la tendenza ad abbandonare la pratica è molto forte, in quanto cosa molta fatica e si ha la sensazione di perdere tempo e di andare lentamente.
Partire da una codebase con molto codice legacy introduce un'ulteriore difficoltà, quindi all'inizio conviene provare ad implementare una feature da zero limitando il più possibile l'uso del codice esistente.
Ricordiamoci infine che il nostro obiettivo è rilsolvere problemi. Un codice di qualità è il mezzo e le feature sono il risultato del nostro lavoro.
Su questo punto consiglio la visione di del video Hammock-driven Development