Testing del codice e TDD: due libri da leggere

Spesso su cosenonjaviste condividiamo le nostre letture informatiche, in questo post vedremo una breve recensione di due libri “scoperti” da poco. Entrambi i libri parlano di testing del codice anche se da due punti di vista diversi. Il primo libro, Growing Object-Oriented Software, Guided by Tests, parla di scrittura di codice nuovo con un approccio basato sui test. Il secondo, Working Effectively With Legacy Code, spiega come i test possono aiutare quando si ha a che fare con sistemi legacy.

Growing object-oriented software guided by tests

Questo libro è stato scritto da Steve Freeman e Nat Pryce ed è stato pubblicato nel 2009. L’autore della prefazione è già un segno della qualità del libro, infatti è stata scritta da Kent Beck, non proprio il primo arrivato nel mondo dello sviluppo software. L’argomento principale del libro è il TDD, Test Driven Development, spiegato con un esempio molto dettagliato che mostra come utilizzarlo nella pratica. Nei vari capitoli sono spiegati nel dettaglio tutti i concetti principali legati al mondo del test, da junit ai mock e agli stub.

Leggendo il libro si capisce bene che il TDD è molto di più di un modo di scrivere i test per il codice, come dice il titolo del libro il software dovrebbe crescere guidato dai test. Scrivendo i test prima del codice di produzione si ha la sicurezza che sia possibile testare facilmente il tutto, questo è il primo passo per avere codice pulito. Il codice testabile è spesso organizzato bene, leggibile e manutenibile con facilità.

Un capitolo molto interessante è quello che parla del testing della persistenza. In una web app è sempre molto delicato capire come testare l’accesso al db, spesso non basta testare il codice Java ma è necessario scrivere dei test che arrivano a eseguire le query sul database per avere una buona copertura del codice. In questo capitolo ci sono dei consigli pratici molto utili per scrivere test su database. Per esempio viene suggerito di pulire i dati nel database prima di eseguire il test e non dopo in modo che, in caso di errori, i dati rimarranno sul db e sarà possibile eseguire query per capire cosa è successo nei dettagli.

L’unico difetto (se così si può chiamare) trovato in questo libro riguarda l’esempio che occupa vari capitoli. Questo esempio è basato sulla libreria Swing, molto diffusa qualche anno fa ma che ormai è usata in pochi progetti. L’esempio è comunque scritto bene e spiega nel modo giusto i concetti del libro ma un esempio basato su framework un po’ più attuali sarebbe risultato più interessante.

Working Effectively With Legacy Code

L’altro libro di cui parliamo oggi è di Michael C. Feathers ed è stato pubblicato nel 2005. E’ della seria di libri di Robert C. Martin, anche in questo caso un nome che è una garanzia di qualità del libro.

Nei primi capitoli introduce due modalità di modifica del codice: Edit and Pray e Cover and Modify. Secondo questo libro la prima modalità è lo standard in molti progetti, si esegue una modifica e si spera di non aver fatto danni! La modalità corretta sarebbe ovviamente la seconda, in pratica si dovrebbe modificare una parte di codice solo quando questo è coperto da test. Ok, discorso corretto e in teoria dovrebbe essere la norma ma purtroppo in pratica non è così semplice da mettere in pratica. Il motivo è ben sintetizzato nel Legacy Code Dilemma:

Quando modifichiamo il codice, dovremmo prima scrivere i test.
Per scrivere i test, spesso dobbiamo modificare il codice.

L’idea per sfuggire al Legacy Code Dilemma è quello di scrivere via via test sempre più approfonditi intervallando la scrittura dei test con dei refactoring e delle modifiche al codice. In pratica si inizia scrivendo dei JUnit test che quasi sicuramente copriranno poco codice, poi si passa a fare un refactoring poco invasivo che sia propedeutico per scrivere test più approfonditi. Mano a mano che la copertura dei test aumenta si passa a refactoring più rischiosi potendo contare sui test che ci confermano di non introdurre errori.

La parte più cospicua libro è costituita da un insieme di pattern da seguire per poter scrivere dei test di progetti legacy. Gli esempi sono molto dettagliati, alcuni sono in Java ed altri in C/C++. Purtroppo essendo il libro del 2005 alcuni esempi sono un po’ datati e spesso non dà per scontato di avere un IDE con un buon supporto al refactoring. Adesso, per fortuna degli sviluppatori, sia Eclipse che IntelliJ che gli altri IDE Java hanno tutti un ottimo supporto per eseguire refactoring del codice senza preoccuparsi troppo di eventuali errori introdotti.

Il testing messo in pratica

La cosa migliore di questi due libri è secondo me l’approccio molto pratico con il quale viene trattato l’argomento del testing del codice. Infatti troppe volte il TDD viene presentato con esempi banali e scelti appositamente per l’occasione. In questi libri invece gli esempi non sono proprio quelli classici, il codice legacy e le interfacce utente non sono proprio così facili da testare.

Buona lettura e buon testing!

Fabio Collini

Software Architect con esperienza su piattaforma J2EE e attualmente focalizzato principalmente in progetti di sviluppo di applicazioni Android. Attualmente sono in Nana Bianca dove mi occupo dello sviluppo di alcune app Android. Coautore della seconda edizione di Android Programmazione Avanzata e docente di corsi di sviluppo su piattaforma Android. Follow me on Twitter - LinkedIn profile