Durante gli scorsi Community Days del 21 e 22 Giugno si è accesa una discussione riguardo ai Dynamic Languages ed in particolare al fatto che questi possano sopperire al problema dei Run-time errors con l'uso estensivo di Unit Testing.
Personalmente mi sono "acceso" a favore degli errori di compilazione che sono i miei migliori amici, scottato nel passato da brutte esperienze a base di variant, vbscript, javascript e memore del prezioso aiuto che invece il compilatore c++ mi ha sempre dato. Non nego per questo l'utilità dei linguaggi dinamici, per esempio per propositi di amministrazione di una rete al posto del più vetusto Windows Scripting Host, magari a fianco della nuova shell Monad.
La discussione ha toccato poi lo Unit Testing e ho "inutilmente" cercato di spiegare come ci siano innumerevoli casi in cui purtroppo sia totalmente inutile e impraticabile. Purtroppo ogni giorno ne ho un riscontro, per esempio solo una settimana dopo l'evento, grazie ad una segnalazione sui newsgroup, ho riscontrato un problema non identificabile con Unit Testing nella mia collection http://www.codeplex.com/RafCollection. Ho implementato il metodo EndNew in modo tale da lanciare una ArgumentOutOfRangeException per indici negativi ... sembra tutto ok e confortato da unit testing. Invece la GridView del Framework 2.0 chiama stranamente EndNew con index = -1 e lo Unit Testing si rivela ovviamente inutile.
Non per questo nego l'utilità di Unit Testing che in molti casi permette una validazione (che nulla ha a che fare con la dimostrazione di correttezza) del codice.
Odio le mode che vedono Unit Testing come panacea di tutti i mali e Edsger Dijkstra, uno dei padri degli algoritimi dell'ottimizzazione (che ricordo bene per aver implementato uno dei suoi algoritmi in C#) aveva già avvertito con un profetico “Program testing can be used to show the presence of bugs, but never to show their absence!”.