Prendo spunto da un post del socio, per dire la mia (non me ne voglia), in merito al TDD e soprattutto ad alcuni dei suoi vantaggi “intrinseci”.
Il ciclo “red-green-refactor”, ai più ormai noto, è, al primo impatto, molto semplice: parti da un test rosso e implementa il codice, il più velocemente possibile, per farlo diventare verde. Solo dopo procedi a colpi di refactoring, a migliorare ciò che hai scritto. Questa frase porta con se alcuni “hidden-statements” che nascondono alcuni dei migliori side-effect del TDD. Uno di questi è la focalizzazione del problema.
L’utilizzo del TDD mi permette di definire, in modo chiaro ed inequivocabile, da dove parto e dove voglio arrivare, magari non seguendo, in prima battuta, la strada migliore. E quindi porre l’attenzione su uno specifico aspetto, senza far deragliare il mio cervello alla ricerca di soluzioni pseudo-alternative.
Il rischio di sovraingegnerazione è dietro l’angolo e divergere dall’obbiettivo preposto, è un costo che è difficile da ammortizzare. L’utilizzo del TDD è “pippa-free”: fai quel che serve alla tua applicazione, in prima battuta, nel modo più smart possibile. Nulla vieta, anzi è auspicato, in un secondo momento (la fase di refactoring, appunto), di affinarne l’implementazione.
Un altro di quegli aspetti che fanno del TDD una metodologia ad alto valore aggiunto è quello di perseguire la semplicità. L’utilizzo di questa metodologia porta con se una metrica molto importante: maggiore è il tempo di ”latenza” in cui un test rimane rosso è un sintomo, abbastanza preciso, di alta complessità. Avere un feedback molto rapidamente sul fatto che la strada intrapresa è troppo tortuosa e quindi difficilmente perseguibile, è un indicatore da non sottovalutare e che permettere di farci intestardire in soluzioni “senza futuro”.
Insomma…va bene il design, va bene la batteria di test implicita che andiamo via via a creare…ma anche il contorno (o forse soprattutto quello), fanno del TDD uno “strumento” sempre più indispensabile nel mio lavoro.
