Quello che gli agilisti non dicono

I vantaggi dei test unitari sono ben noti a tutti: miglioramento del design, documentazione del codice, aumento della qualità tramite la diminuzione dei bachi e la possibilità di ristrutturare il codice in modo sicuro. Quello che gli agilisti (a volte) non dicono è che i test unitari, pur portando tutti questi benefici, rappresentano anche un costo nel processo di sviluppo. Un primo costo è banalmente rappresentato dal tempo necessario per il loro sviluppo, ma questo non è l'aspetto principale del problema. L'onere principale dei test, forse più difficile da cogliere, ci è indicato proprio dalle metodologie agili: tutto il codice prodotto comporta un costo di manutenzione, anche lo stesso codice di test.
Occorre quindi saper capire quando il prezzo dei test sia ripagato dai benefici e quando no. La mia opinione è che la creazione di test approfonditi per le interfacce grafiche non è quasi mai "economicamente" conveniente. Riprendo qui alcuni esempi che ho portato in una discussione nata con Matteo Vaccari sulla lista dell'XP User group di Bergamo.

Qualche anno fa, penso fosse il 2003, assistetti ad una presentazione al Webbit nella quale Bruno Bossola mostrò come fosse possibile applicare il TDD alla realizzazione di interfacce Swing, andando a testare lo stato dei vari "model" dei componenti. Tornai a casa entusiasta e provai a mettere in pratica la lezione: fu un disastro! Questo per due motivi. In primo luogo non sono un programmatore valido come Bossola (e allora ero ancora molto meno esperto). Secondariamente lo sforzo per cercare di domare le idiosincrasie di Swing non portava alcun vantaggio. I problemi della GUI sono al 90% del tipo: "Se visualizzo la mia maschera a 800x600 anziché a 1024x768 i bottoni scompaiono", oppure "Se passo a 1280x1024 il carattere è così piccolo che non si legge una fava". Certo, il debugging di questi aspetti si può fare anche con il TDD, ma penso che il debugging umano sia insostituibile, più efficace e molto meno costoso.

Secondo esempio. All'XP UG di Milano tentammo di sviluppare l'UG-Aggregator, una mini applicazione web per inserire e visualizzare gli eventi dei vari XP-UG. Questa applicazione non aveva alcun tipo di logica significativa, ma noi, essendo agilisti DOC, dovevamo scrivere i test! Ci venne quindi l'idea di testare la struttura dell'HTML prodotto, per vedere che ci fossero determinati tag con attributi che dovevano identificarne il contenuto. Il risultato fu circa il seguente, correggimi se sbaglio: tempo per scrivere il codice 1, tempo per scrivere il test 2, tempo per debuggare il test (e non il codice) che non funzionava 4. (OK ho un po' esagerato, ma penso che la mia ricostruzione non sia troppo lontana dalla realtà). Questo a mio avviso è un esempio di programma senza logica per cui il TDD può non essere efficace. Inoltre in questa situazione modificammo non solo la struttura interna dell'applicazione per renderla più testabile, ma anche il suo comportamento. Questa ritengo sia una "puzza" del processo di test!

In questo senso mi ha confortato l'esempio di TDD presentato nell'ultima riunione dell'XP User Group di Bergamo da Alessandro melchiori e Emanuele DelBono. Partendo dai test è stata abbozzata una banale applicazione Windows secondo il paradigma Model - View - Presenter. Ebbene, tutto il codice risultava coperto da test, ad eccezione della parte di view!
(Un unico neo nella presentazione dei due amici bresciani: tutto in C#!!!) ;-)

Pleasures of boilerplate code

In a very interesting interview, Martin Odersky said that Scala could be a little more difficult than Java for newcomers because in it you have not to write boilerplate code, but you have to think at your problem just from the first line of code. In some way, boilerplate code could be a kind of "warming up" for beginners. Writing some code, even if it's only syntactic noise, could give confidence to the programmer, generating a feeling of accomplishment.

But, is there a way to warm up without writing silly code? The best way of doing this is with unit testing. In TDD by example , Kent Beck describes "Starting tests": Start by testing a variant of an operation that doesn't do anything. Using these tests, not only you can start exploring your design, but you can also break the "white sheet syndrome".

Il crepuscolo dello Sviluppo Agile?

In un post molto interessante di James Shore leggo "Because Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design. Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt."
Ovviamente l'autore pensa che ciò sia dovuto ad un cattivo impiego di Scrum, nel quale vengono tralasciate le seguenti pratiche:

  • spazi di lavoro condivisi o tecniche che enfatizzino al massimo la comunicazione;
  • contatto strettissimo con il cliente;
  • gruppi di lavoro interfunzionali;
  • pratiche di ingegneria del software prese da XP (EXtreme Programming): penso a refactoring, TDD, continuous integration.

Ma ciò sarà davvero sufficiente a colmare il debito tecnologico maturato con l'abbandono dell'up-front design?
Qualcosa su questi temi si sta muovendo, ne sia prova il recente thread sulla lista extremeprogramming-it dal titolo Perche' il design emergente non e' robusto?. Ovviamente scopo del thread era quello di cercare di confutare questa tesi, ma mi sembra che in ogni caso dei dubbi stiano emergendo.

Ora devo scappare, ma concludo segnalando un questo post al vetriolo sull'argomento. Forse qui si esagera, però.....

Italian Agile day 2008


Agile day

Annunciato l'Italian Agile Day 2008, la conferenza gratuita sulle metodologie agili, giunta alla quinta edizione. L'appuntamento è per il 21 novembre a Bologna. Non mancate!