Il TDD mi piace, è cosa nota, ma non uso TDD per tutto, anzi lo uso poco. In questi giorni ho però trovato un “campo” di applicazione in cui il TDD è la manna.

• Avete una codebase esistente, coperta da test;
• Avete la necessità di apportare modifiche/aggiungere funzionalità, che impattano (o potrebbero impattare) anche sul codice esistente;
• Avete, eveidentemente, la necessità di non spaccare tutto… :-)

In questo scenario, non poi così raro, TDD è la soluzione a tutti i mali :-)

1. definite a monte le funzionalità che volete soddisfare, riducendo la superficie di rischio perchè non vi fare trascinare dalla mania del developer di aggiungere un sacco di fuffa… perchè è noto che in caso di guerratermonucleareglobale il nostro componente deve funzionare lo stesso :-);
2. vi garantite che anche il nuovo codice sia coperto da test, il che non guasta: un test al giorno leva il bug di torno… pietoso :-);
3. I test esistenti vi garantiscono che le funzionalità/comportamenti precedenti vengano comunque rispettati;
4. Procedete per piccoli passi con moltissima confidenza, perchè se ad ogni build fate anche girare i test (magari solo quelli “scoped”) sapete che quello che avete toccato non spacca tutto, il che non è che faccia male :-);

e… la confidenza in scenari come questo è tutto!
.m