Mentre noto che da qualche anno si parla molto di testing, mi pare di rilevare una minore attenzione verso uno degli attributi fondamentali del software, almeno stando agli standard internazionali ISO/IEC--la testabilità del software.
Cosa conta di più, allora?
Beh, il testing è sotanzialmente il risultato dell'esecuzione di una serie di programmi ad hoc (OK, intendo automated testing) volti ad assicurare che le classi (unit) o il sistema nel suo insieme si comportano come ci si aspetta in relazione al codice ed eventualmente a componenti esterni.
Il testing ci dice che il software funziona. O più esattamente ci dice che le funzioni/scenario che abbiamo testato funzionano. Il che non è male, ma non è nemmeno certezza assoluta. Come scriviamo con Andrea in "Architecting Applications for the Enterprise", il testing e in particolare lo unit-testing serve solo al team per darsi la sicurezza che si sta procedendo sulla giusta strada e per crearsi uno strumento di difesa contro regressioni post-modifiche.
La testabilità, invece, ci porta a scrivere codice che sia semplice da sottoporre a unit-testing. E come è possibile ciò? Sostanzialmente facendo uso di principi di design e opportuni pattern. Alla fine, il paradosso sapete qual è? E' che la testabilità serve non direttamente al testing, ma ad avere soprattutto codice migliore e meglio disegnato. Il testing è una scusa per dedicarsi seriamente alla testabilità.
E la testabilità del codice comincia dalla definizione di software contracts. O come li chiama MS (che deve sempre distinguersi...) code-contracts. Oggi anche per VS 2008 in attesa di .NET 4.0 e VS2010.
Certo talvolta la testabilità rischia di fare a pugni con la purezza del design OOD. Ma la ricerca della testabilità porta a codice più flessibile, modificabile e anche leggibile. E se poi non è puro OOD... chi se ne frega. E se, come dice un esperto del campo--il mio amico Roy Osherove--fosse ora di cambiare alcune definizioni di OOD?