Posts
83
Comments
165
Trackbacks
11
Framework di test: MbUnit vs NUnit

Da un paio di anni la mia scelta sul framework di test da utilizzare nello sviluppo delle applicazioni è ricaduta su MbUnit per vari motivi: soprattutto per la possibilità di eseguire test parametrici e per alcune funzionalità molto utili tipo la possibilità di eseguire i test di integrazione in modalità transazionale tramite l’attributo Rollback, garantendomi la “pulizia” del mio db di test, tra uno unit-test e l’altro.

Ultimamente però, come altri hanno sottolineato anche in un thread sulla mailing list di UgiAlt.Net, ho avvertito la necessità di “guardarmi” un po’ attorno. MbUnit sta prendendo una direzione un po’ strana (la versione 3.0, per esempio, è fortemente accoppiata con Gallio) che non condivido, partendo dalla necessità di un’installazione vera e propria (con tanto di cartella MbUnit in Program Files) per poter usufruire di una semplice dll.
Il primo requisito che un framework di test deve rispettare è la semplicità di start-up e mi sembra che MbUnit si stia sempre più allontanando da questa “strada maestra”.

Dato che oggi ho avuto un po’ di tempo libero ho provato a riguardare NUnit, che avevo abbandonato un paio di anni fa proprio per MbUnit. Siamo arrivati alla versione 2.4.8 (2.5 Beta1) e, con mio sommo piacere, ho appreso che dalla versione 2.4.7 hanno integrato un nuovo namespace (nunit.framework.extension) che espone l’attributo RowTest e quindi la possibilità di eseguire test parametrici.

Molto bene…scarico la versione in beta e provo!!!
Molto male…il namespace nunit.framework.extension della versione 2.5 non contiene gli attributi RowTest e Row…cominciamo bene :-S
Facendo il downgrade alla versione attualmente “in produzione” (la 2.4.8) tutto inizia a funzionare…molto bene.

Una novità, che ho molto apprezzato, è la nuova modalità di “scrivere” gli assert dei nostri metodi di test: il constraint model.
Affiancata alla modalità “classica”, mantenuta per retrocompatibilità, di eseguire asserzioni (n metodi della classe Assert), ora tutto passa attraverso un unico metodo e un insieme di constraints (integrabile a piacere) che, secondo me, rendono il test molto più leggibile:

[NUnit] Assert.That

Da una prima valutazione molto veloce, l’unico “disguido” (di non poco conto) è la mancata integrazione con il runner di ReSharper per l’attributo RowTest.
Indagherò più approfonditamente nei prossimi giorni…comunque l’impressione è assolutamente buona!

melkio

posted on martedì 6 gennaio 2009 00:19 Print