Uno
dei vantaggi più grandi dell’avere un software di Continuos Integration è la
possibilità di eseguire gli unit test ad ogni checkin, questa pratica è
fondamentale ed è importante per stabilire la correttezza di una build. CC.NET
fornisce il supporto nativo per l’analisi del risultato dei test di NUNIT e una
delle differenze più sostanziali rispetto all’analisi con FxCop è che la build
del progetto viene considerata fallita se uno degli unit test fallisce, in
questo modo si viene subito avvertiti che qualche cosa non va e si deve
immediatamente procedere al fix del test o dei test che non producono risultati
corretti. Come per l’FxCop il primo passo è aggiungere allo script di NANT un
task per eseguire i test con NUnit, contenuti naturalmente in un apposito
assembly separato.
<target name="NunitUnitTest" depends="CompileDebug">
<delete dir="${OutputLogsDir}\Nunit" failonerror="false" />
<nunit2 haltonfailure="false">
<formatter type="Xml" usefile="true" extension=".xml" outputdir="${OutputLogsDir}\Nunit" />
<test>
<assemblies>
<include name="${ProjectDir}\UnitTest\bin\debug\UnitTest.dll" />
</assemblies>
<categories>
<exclude name="CategoryToExclude" />
</categories>
</test>
</nunit2>
</target>
Come si può vedere il
task inizia semplicemente con la cancellazione completa della directory che
contiene i file di log delle build precedenti. La variabile OutputLogsDir era già stata esaminata nel post
precedente e contiene la directory dove CC.NET si attende di trovare tutti i
file di log prodotti dai vari task post build che vengono
eseguiti.
Per i test di NUnit è
presente un task specifico NAnt chiamato nunit2. Come si può vedere il test è
settato per non fermarsi al primo fallimento, in questo modo veniamo avvertiti
di tutti i test che falliscono, anche se a tutti la build viene considerata
fallita se anche un solo test fallisce. Il task nunit2 deve contenere al suo
interno l’elemento formatter che forza la generazione di un file di log XML
nella directory di output, in questo modo CC.NET può esaminare il risultato dei
test ed eseguire l’azione corrispondente. L’elemento più importante è chiamato
test e deve contenere la lista di
tutti gli assembly che contengono i test da eseguire. Nel caso in esame tutti i
test sono contenuti nel progetto UnitTest e pertanto basta indicare il
file ${ProjectDir}\UnitTest\bin\debug\UnitTest.dll.
Oltre a queste impostazioni base nunit2 permette di specificare le categorie da
eseguire con l’elemento categories.
Quello che si fa normalmente è infatti escludere dall’esecuzione eventuali
categorie che magari rappresentano test particolari e che necessitano di
impostazioni particolari per essere eseguiti.
L’unica modifica da
effettuare per il file ccnet.config è invece aggiungere il nuovo file nella
lista dei file esaminati dal publishers.
<publishers>
<merge>
<files>
<file>F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\OutputLogs\FxCop.xml</file>
<file>F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\OutputLogs\Nunit\UnitTest.dll-results.xml</file>
</files>
</merge>
<xmllogger/>
</publishers>
Come si può vedere se uno
solo dei test fallisce la build stessa fallisce e grazie al Web Dashboard siamo
in grado di capire quanti e quali test sono falliti.
Un’altra informazione
interessante sono i tempi di esecuzione dei test, che possono essere quindi
anche utilizzati per eseguire un rudimentale test di prestazioni del software in
esame.
Alk.
powered by IMHO 1.3