In questi giorni io e soprattutto il mio "compagno
di banco" Roberto abbiamo fatto parecchio lavoro per mettere in
piedi un sistema di continuous integration in azienza, appoggiadoci ai classici
tool open source quali CruiseControl.NET, NUnit, NAnt, NCover e compagnia.
Seppur sudando un po', siamo arrivati a quello che volevamo, e penso che Roberto
posterà qualcosa in merito. Io invece approfitto per descrivere un problema che
abbiamo incontrato e come lo abbiamo "risolto".
NUnit, che per n motivi che non sto a descrivere abbiamo preferito a MSTest
di Microsoft, funziona ovviamente molto bene, ma ha un baco noto: se sulla linea
di comando (quindi usando nunit-console, ma anche la gui ne è affetta)
specifichiamo più di un assembly di test, e se questi necessitano di file di
configurazione diversi tra loro per poter funzionare, i file di
configurazione non vengono letti. L'unico caso che funziona è quello in cui
viene specificato un solo assembly, se per esempio esso si chiama MyTests.dll
verrà cercato e caricato un file di configurazione MyTests.dll.config. Se
invece gli assembly sono per esempio MyTests1.dll e MyTests2.dll, non
vengono cercati e caricati MyTests1.dll.config e MyTests2.dll.config, bensì un
unico file Project1.nunit.config (!!) che viene usato come file di
configurazione per tutti gli assembly. Questa situazione, che nasce da una
gestione scorretta dell'AppDomain in cui vengono fatti girare i test provenienti
da più assembly, per noi non era accettabile e minava l'infrastruttura di
continuous integration, al che, in un attimo di potenziale follia, ho detto: "mi
tiro giù i sorgenti e lo sistemo, checcivuole?" 
Beh, l'ho fatto davvero! Presumevo che
NUnit fosse scritto sufficientemente bene e che quindi non sarebbe stato improbo
farlo, e così è stato, in mezza giornata ho aggiunto un flag sulla linea di
comando che fa creare tanti AppDomain quanti gli assembly e per ognuno carica il
file di configurazione denominato con la notazione <nome
dell'assembly>.config, producendo infine un "merge" dei vari output
conforme a quello generato da NUnit normalmente. E' una "toppa" ed in quanto
tale non è "annegata" nell'infrastruttura di NUnit (non avevo il tempo di
approfondirla troppo) bensì si posiziona al di sopra di essa, non è
elegantissima ("partial class" a go go, per fare prima ) ma è efficace. Comodi, i
sorgenti...
A questo punto ho pensato che avrei potuto verificare se il mio lavoro
potesse diventare un contributo effettivo ad NUnit e non rimanere confinato al
nostro ufficio, e sono andato a curiosare sul sito di NUnit scoprendo che è
disponibile una beta 1 della versione 2.4 che sistemerà il problema, quindi per
fortuna il mio contributo non servirà a nessuno ma nell'attesa noi potremo procedere
senza attendere la versione ufficiale. Ma leggendo oltre ho trovato anche una
cosa "strana": tra le indicazioni su come contribuire al progetto, ho visto come
per loro il TDD vada preso alla lettera: non si accetta niente che non sia
corredato di test, ovviamente tutti verdi. Ma allora... perchè dei 760 e
rotti test a corredo dei sorgenti di NUnit ben 36 sono rossi?? Mi ha sorpreso,
mi sfugge qualcosa o anche a voi non quadra?? Oppure è considerato
accettabile avere dei test rossi?? A me sembra strano, cercherò di
approfondire...
powered by IMHO 1.3
posted @ martedì 29 agosto 2006 00:12