Dopo un quarto d'ora di yoga ho deciso di andare a vedere la sessione su TDD. La sessione è priva di slides, agenda agile (scritta a manina dal relatore) e domande libere da parte del pubblico. Purtroppo il risultato è stato di andare completamente fuori tempo... due domande risposte su sei fatte dal pubblico.
La demo presentata riguarda due banalissime pagine web che pubblicano una lista di titoli di libri da cui poi si possono vedere i dettagli.
Lo speaker pone l'accento sulla separazione della vista dal controller, e fin qui sono daccordo ma con TDD non ha proprio niente a che fare. La solution completa è composta da circa 7 assembly 
. Poi mostra il codice e dopo i test ... uhm, c'è qualcosa che non va.
A questo punto mi chiedo come conciliare tutto quel codice con i soldi del cliente... se lavoro a giornata, il cliente paga codice che potrebbe anche non servirgli mai; se lavoro a commessa, la mia offerta sarà troppo alta.
Le altre cose che non mi hanno convinto nel codice sono:
- Assenza di gestione degli errori nel codice delle viste (asp.net). Le eccezioni lanciate dal controller contenevano informazioni che possono dare informazioni preziose ad un eventuale hacker.
- Le eccezioni lanciate andavano direttamente nella view senza alcun log ... sigh
- I test erano a fronte di una sorgente dati fittizia, il che apre il problema di come controllare che siano sempre allineati, con dati sufficienti a fare test, e con quali criteri sono stati scelti.
- L'uso dell'obejctdatasource di asp.net mi ha lasciato decisamente perplesso
- Creazione di oggetti senza mantenre un reference locale ... si vede che lo speaker non usa il debugger! Il debugger non è uno strumento sostituibile. Anche se il risultato è corretto, il codice può essere terribilmente sbagliato,
Devo partira dal presupposto che lo speaker sia un esperto di TDD e che ha sviluppato quell'esempio usando un approccio TDD. Quindi anche se è andato off topic mi sarei almeno aspettato del codice soddisfacente.
Avrei voluto sentire buone motivazioni su TDD, cioè quali siano i vantaggi reali nel disengare prima i test di cominciare a scrivere codice, e non li ho sentiti nè ho visto codice che mi potesse far intuire una metodologia convincente che bilanci il mio tempo con i soldi del cliente.
Nei progetti che seguo e ho seguito in passato le specifiche non durano così tanto eppure riusciamo a fare consegne ogni settimana proprio per seguire i continui cambiamenti. Non mi ha convinto, ma pazienza, se qualcuno trova dei vantaggi nel TDD, buono per lui.