Uncle Bob nel suo libro “The clean coder” descrive il TDD (Test Driven Development) come: "una disciplina che esalta la certezza, il coraggio, la riduzione dei difetti, la documentazione e il design” e considera poco professionale non usarla.
Incuriosito da queste parole, ho approfondito il TDD sempre di più, prima studiandone la teoria e poi applicandolo nella vita lavorativa quotidiana.

L’elemento che mi attraeva maggiormente era la promessa che tramite questa tecnica fosse possibile rimuovere la paura del refactoring.
Niente più timore nel modificare codice esistente, niente più bug inaspettati, libertà nel cambiare e modellare il codice a proprio piacimento!
Non è forse questo il sogno di ogni sviluppatore?
Tutto ciò grazie ai test che avremmo scritto prima del codice di produzione. Essi sarebbero rimasti al nostro fianco a proteggerci e a farci da spalla come fedeli alleati.

Purtroppo però tale sogno per me non si realizzava.

Molte volte mi vedevo costretto a modificare decine di Unit Test e Mock a causa dell’introduzione di una nuova classe o di un design pattern.
I test risultavano essere fragili; essi erano più un ostacolo al cambiamento che un sostegno allo sviluppo.

Se come me avete provato o provate queste stesse frustrazioni nell’utilizzo del TDD questo talk è per voi!

In questa sessione vorrei condividere la mia esperienza e gli errori che ho commesso in questi anni, cosa ho imparato da essi e come li ho corretti.
Mostrerò degli esempi concreti, cercando di fare chiarezza su qual è effettivamente l'essenza del TDD e su come si possano ottenere dei test efficaci che ci supportino nello sviluppo.