Durante il Workshop "Architecture & Management" parlando di Design inevitabilmente per alcuni attimi abbiamo riflettuto sulla community Java e sul fatto che questi temi sembrano più radicati in quella community piuttosto che nella nostra .NET.
Questo Blog sullo Unit Testing del Db segnalato da Lorenzo mi fa pensare alla Sindrome da Trucchetto.
Come Cappuccetto Rosso quando prende la scorciatoia X il bosco... ed i guai hanno iniziano, cosi a volte ho la sensazione che conoscere come possono essere fatte le cose e farle in quel modo sia considerato un... delitto perché sicuramente deve esistere un trucchetto che risolve tutto e di più!
Nel blog ad esempio viene suggerito di usare le transazioni COM+ per testare classi che usano il Db. Chi ha usato COM+ sa quanta complessità introduce, quanta conoscenza richiede e quanti problemi di instabilità ad ogni patch può creare se i Db in gioco sono diversi da SqlServer; tutto viene bilanciato dalla potenza e dalla flessibilità di COM+ quando ciò è necessario e viene realmente sfruttato.
Alla domanda <<serve davvero scomodare COM+ par fare Unit Testing di una applicazione con Db?>> quindi mi rispondo di no: ci sono solo pochi e rari casi limite in cui questo trucchetto può rilevarsi conveniente ed anche in quei pochi casi per decidere se davvero usare questo trucchetto è importante prima conoscere e valutare la strada maestra:
- Usare script di preparazione del Db di test da richiamare nel SetUp del test
questa tecnica ha il vantaggio di essere semplice e poter essere impiegata in applicativi già esistenti quando si comincia a fare unit testing; richiede tool per creare script di creazione del db e di inserimento dei dati a partire da un db esistente e una classe C# per lanciare script esterni (.cmd, .bat o .sql)
- Usare i Mock Objects
questa tecnica ha il vantaggio di isolare le classi testate dal Db rendendo più efficaci i test e promuovendo un migliore disaccoppiamento tra le classi che si stanno sviluppando; richiede una discreta competenza di Design per abilitare in maniera armonica le classi sviluppate ad usare i Mock Objects
Sono il solo ad avvertire questa Sindrome da Trucchetto che colpisce la nostra community .NET come un peccato originale (siamo tutti figli del glorioso VB)?
Ho interpretato come "sentire comune" la distinzione fatta da Lorenzo all'inizio della sessione "Pattern and Practice & Application Blocks" in cui distingueva tra programmi progettati e programmi RAD da Wizard e Drag & Drop cosi come in questo blog di Luca Mauri e in questo blog dell'amico Riccardo Golia.
Ma se mi sbaglio basta dirlo, sono disposto a ricredermi ;-)