Chi usa scrivere unit-test sa bene che in molti dei framework disponibili oggi è possibile creare un metodo che viene eseguito prima di ogni test decorandolo con l'attributo [Setup] ed un metodo che viene eseguito dopo ogni test decorandolo con l'attributo [TearDown]. James Newkirkin, uno che unit-test ne sa' , in questo post sostiene che questa pratica ha più svantaggi che vantaggi tanto che nel nuovo framework xUnit tali attributi non sono presenti. A questo indirizzo viene spiegato dettagliatamente come raggiungere lo stesso risultato con xUnit senza ricorrere all'utilizzo dei metodi decorati con gli attributi [Setup] e [TearDown] . Personalmente ho sempre utilizzando gli attributi senza avvertire...

Da oggi è disponibile su codeplex la versione 1.0 del nuovo framework creato dal James Newkirk e Brad Wilson. Tra la documentazione è presente anche una pagina di confronto con i framework già esistenti. Peccato che per ora manchi ancora il confronto con mbUnit. Interessante la possibilità di avere già da questa versione l'integrazione con TestDriven.NET per me fondamente per ogni framework di test che si rispetti. Altri dettagli sul progetto li trovate qui. Technorati tags: unit test, xunit, mbunit

Da qualche tempo ho notato in rete un certo interesse verso il Behaviour Driven Development (abbreviato in BDD). Sul sito viene data questa definizione : Il Behaviour-Driven Development (BDD) è una evolozione dei concetti alla base del TestDrivenDevelopment e del AcceptanceTestDrivenPlanning. Ovviamente esistono diverse implementazione (vedi tools) a seconda della piattaforma su cui si sviluppa. Per chi usa il framework .NET consiglio di dare un'occhiata a questi due progetti: specter che usa Boo come linguaggio per creare i test. Sul sito è presente anche un buon video su come usarlo. Behave# che usa C#, un esempio lo trovate su wiki del progetto. Altri...

In questo ultimo periodo ho usato molto il pattern ModelViewPresenter. Per scrivere le mie triadi MVP ho utilizzato la tecnica del presenter first con ottimi risultati. All'interno dei miei unit-test ho fatto ampio uso di Mock Objects ed ho notato una certa ripetitività nel codice prodotto, soprattutto nei metodi di Setup e di TearDown. Con una soluzione simili a quella usata per il refactoring del presenter, ho usato i generics ed una classe base per evitarmi inutili ripetizioni. Vediamo un esempio concreto. Di seguito un presenter con la sua View ed il suo Model     public interface IMyView     {       void ShowLoggedUser(string s);    }   public interface IMyModel   ...

Come bloggato qualche tempo fa, nel mio team abbiamo messo in piedi un build server e per farlo abbiamo scelto CI-Factory. Il processo non è stato immediato ma devo dire che il risultato sta portando alcune soddisfazioni. Prima ho scritto "abbiamo messo in piedi un build server " invece di installato perchè la vera e proprio installazione e configurazione base di CI-Factory non è un processo molto complicato. Per avere la prima build basta poco.L'attività che richiede più tempo è sicuramente la configurazione dei molti package disponibili: Alerts , Analytics , CSDiff , DotNetUnitTest , FinalBuilder , InstallShield , MSBuild , MSTest , NCover ,...

Oddio cosa ho scritto. Ma in fondo è solo la pura verità. Stuzzicato dal post di Raffaele non ho potuto trattenermi dal postare anch'io e spendere 2 parole sull'argomento. Al mio commento Raffaele ha risposto : "Unit Testing non può essere una base per validare un software. È solo uno dei tanti sistemi che può rivelarsi più o meno utile a seconda dei casi" Io qui ribatto con: Sicuramente usare solo unit test non basta, ma se parliamo di test ce ne sono diversi tipi e riuscire ad automatizzarli invece che affidarsi ad un tester ha dei vantaggi oggettivi. Certamente non sempre è una attività...

Attualmente partecipo allo sviluppo di un progetto dove abbiamo circa 500 unit-test, 1.000 assert ed il tempo di esecuzione di tutti i test si avvicina ai 5 minunti. Questo porta a non eseguire sempre tutta la suite di test. Per esempio se modifico una singola classe modifico o aggiungo qualche test, scrivo il codice per far passare solo i test che mi interessano in questo momento e quando quest'ultimi sono ok faccio il commit sul source control. Così facendo però corro il rischio di aver fatto il commit di codice che potenzialmente fa fallire gli altri test che non ho eseguito ma d'altro canto non posso sempre "perde"...