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#!!!) 
Gabriele Lana:
Ciao Franco, mi ricordo molto bene l’episodio all’XPUG di Milano e hai perfettamente ragione, però per me stai traendo giuste conclusioni (insostenibilità economica) da false premesse (codice non testabile automaticamente). Premetto che concordo con il fatto che alcune cose dovrebbero essere testate dagli umani e non dalle macchine, e infatti per me dovrebbe essere solo questa la discriminante per decidere se automatizzare un test o meno, non l’inadeguatezza dello stack tecnologico che stiamo utilizzando
Ovvero: se un pezzo di codice non risulta facilmente testabile (vuoi per come è stato scritto, vuoi per la tecnologia in cui è stato scritto), prima di chiudere il discorso dicendo che costerebbe troppo testarlo, io mi chiederei:
- perchè costa troppo
- se costasse meno lo testerei e perchè
- se posso fare in modo (implementandolo diversamente o cambiando tecnologia) che costi di meno testarlo
Concludo dicendo che è vero che il nostro aggregato all’XPUG non aveva alcuna logica di business, ma ti faccio presente che qui stiamo parlando sopratutto di sostenibilità dello sviluppo del software, della possibilità di un software di evolvere nel tempo, di abbracciare il cambiamento, se non riesci (perchè troppo costoso) a testare un’applicazione banale, questo non ti fa nascere qualche dubbio? A me si, di brutto, infatti l’esperienza all’XPUG mi ha portato un grande insegnamento
28 Marzo 2009, 9:41 amaniello:
sono daccordo che i test sono utilissimi ma come tutti gli strumenti non vanno esasperati, ma la tua esperienza con la realizzazione dell’ UG-Aggregator è certamente un esempio di cattiva applicazione della metodologia, ma l’errore fondante è stato scrivere i test alla fine, pratica che non credo certo si possa associare in alcun modo al TDD.
28 Marzo 2009, 11:06 ama presto
Franco Lombardo:
@Gabriele - Hai ottimamente sottolineato un aspetto: la testabilità deve essere economicamente sostenibile, quindi se testare il codice di una GUI fosse semplicissimo si potrebbe pensare di farlo. Noto però che, come giustamente dici tu, il valore maggiore del test non sta nell’eliminazione dei bachi, quanto nel formare un codice che abbracci il cambiamento, soprattutto nelle logiche applicative. C’è quindi da chiedersi se questi ipotetici test “gratuiti” della GUI non sarebbero comunque troppo fragili, non catturerebbero comunque aspetti non essenziali, ma contingenti dell’applicazione. Questa loro insita fragilità non sarebbe comunque un freno al cambiamento?
@Aniello - In realtà l’UG-Aggregator è stato sviluppato in modo “Test Driven”.
28 Marzo 2009, 5:08 pmGabriele Lana:
Chiarissimo, infatti la mia domanda (alla quale ancora non ho trovato risposta) è: la difficoltà/fragilità dei test delle UI (nota l’assenza della G) esiste a prescidere o è direttamente collegata alla tecnologia implementativa? Se fosse un problema tecnologico e se riuscissimo a risolverlo questi test avrebbero un valore? Sosterrebbero il cambiamento?
In uno dei progetti in cui sono coinvolto adesso, i test automatici coprono un’alta percentuale del codice che è stato scritto in maniera test driven, purtroppo l’interfaccia non è testata, indovina gli unici bug che sono finiti in produzione dov’erano localizzati? Stiamo parlando di mispelling nelle label, piccoli errori nel processo di build che rompe un link, ecc… Tutte cose stupidissime ma percepite in maniera forte dall’utente. Possono anche essere testate manualmente, ma più l’applicazione cresce più ne cresce il costo collegato
31 Marzo 2009, 11:48 amFranco Lombardo:
@Gabriele - Il tuo punto di vista è condivisibile. Ovviamente se creare un test per un’etichetta sulla (G)UI costa 1.000 euro, ed avere l’etichetta sbagliata in produzione ne costa 10.000, è ovvio che il test si deve fare! Io non mi sono mai trovato in situazioni simili, ma riconosco che possano esistere.
31 Marzo 2009, 1:41 pmAlberto Gori:
Sicuramente il testing della GUI è la meno efficacie in quanto la GUI tende ad essere troppo volatile, e ad esempio la modifica di un semplice tag può comportare il fallimento del test, o peggio di una batteria di test.
Tuttavia è possibile limitare i danni usando certi strumenti e metodologie. Nel web (l’unico GUI testing su cui ho un minimo di esperienza) è molto conveniente l’utilizzo degli identificatori per rendere facilmente tracciabili gli elementi nella pagina. Anche l’uso di CSS rende più scarna e testabile la pagina.
Per quanto riguareda i tool, sicuramente Selenium è ottimo. Si può utilizzare su svariati browser e tramite un plugin per Firefox si possono anche creare delle macro. Una volta salvate in forma di test, sono ottimi punti di partenza per il tuo test case.
12 Aprile 2009, 7:23 pmFranco Lombardo:
@Alberto - Concordo con te: il testing delle GUI è inefficace perché la GUI è volatile. Solo che alcuni agilisti, nascondendosi dietro a tool come Selenium, a volte tacciono su questo fatto.
A proposito di Selenium, vorrei citare il bel post di Matteo Vaccari:
“Selenium and similar tools are useful, but secondary; what a programmer needs the most is to learn how to do it right, not write a new tool.”
Spesso ci si dimentica che il fine dello Unit Testing è creare un design efficace, mentre la verifica di correttezza è un utile sottoprodotto, come si diceva tempo fa’ sulla lista XP-IT.
13 Aprile 2009, 10:57 amAlberto Gori:
@Franco
Non sono un profondo conoscitore delle metodologie agili. Tuttavia la mia impressione è che il TDD sia una delle metodologie applicabili e se si da come per scontato che il TDD sia il miglior metodo sempre e comunque allora certamente quello che dici ha senso.
Ma io credo che in taluni ambiti si possa utilizzare il testing automatico anche per altri scopi e con grande successo, e non con il primo obiettivo di un design efficace. Uno di questi sembra essere il testing delle GUI.
14 Aprile 2009, 7:29 pm