Unit test e build server

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" 5 minuti per controllare che tutto si ok.

La soluzione a questo problema è far eseguire i test a qualcun'altro, ovvero un un build server. Io ho scelto CIFactory ovvero un CruiseControl.NET preconfezionato e preconfigurato. L'installazione è abbastanza semplice per chi in passato ha già provato CruiseControl.NET ed è comunque disponibile anche uno screencast piuttosto dettagliato su come installarlo.

Utilizzando un sistema di questo tipo sono sicuro che dopo ogni commit su mio source control tutti gli unit-test vengono eseguiti completamente ed ho diversi sistemi per ricevere notifica del risultato di questa operazione. Utilizzando uno strumento di questo tipo è inoltre possibile automatizzare una lunga serie di operazioni quali versioning , tagging,  code analisys, code coverage, creazione di pacchetti di setup, statistiche sul codice, diff sui file modificati. Alcune operazioni possono sembrare superflue ma avere sempre a disposizione metriche aggiornate sul codice da noi prodotto "senza sforzi" permette di mantenere la qualità del codice elevata riducendo i tempi ed i costi.

 

posted @ mercoledì 27 giugno 2007 23:52

Print

Comments on this entry:

# Re: Unit test e build server

Left by papo at 28/06/2007 12:24
Gravatar
in realta' non hai *risolto* il problema, prima o poi qualcuno dovra' fixare il codice che ha 'rotto' la build. hai soltanto aggiunto un ritardo tra quando il problema e' stato introdotto (durante la scrittura del codice), a quando il problema sara' visibile (la build di CC.NET che fallira').

in realta' chi notera' che la build si e' rotta potresti non essere tu (o chi ha aggiunto il codice incriminato) e quindi sara' piu' difficile localizzare e correggere l`errore.

5 minuti non mi sembrano affatto molti, prova a considerare i vantaggi che hai nel feedback immediato sulla correttezza del tuo codice, rispetto a dover correggere a posteriori l`errore di qualcun`altro.

in azienda noi seguiamo una politica di questo tipo: mentre sviluppi esegui solo i test della parte che *pensi* sia influenzata dal nuovo codice (classi correlate e qualche test di accettazione che tocca quella parte), ma poi prima di integrare e committare le modifiche viene eseguita tutta la suite di test, due volte: la prima solo sulla propria versione del codice, la seconda dopo aver prelevato le modifiche dal repository e corretto i conflitti.

questo perche' la rottura di una build e' una cosa seria: in alcune aziende ci sono riti di fustigazione pubblica dei colpevoli (cappelloni ridicoli da dover indossare per tutto il giorno) o sirene di allarme che suonano per l`ufficio! questa invece e' una lava-lamp collegata a CC.NET
http://mark.michaelis.net/Blog/BuildStatusUsingLavaLampsByKenNichols.aspx

ciao!
-papo-

# Re: Unit test e build server

Left by papo we(b)log at 28/06/2007 12:32
Gravatar

# re: Unit test e build server

Left by makka at 29/06/2007 22:22
Gravatar
Ciao,
sicuramente lo scenario che ho proposto può non essere una soluzione praticabile sul alcuni progetti ma nel mio caso far fallire una build non è ancora un’evento tragico. Cosa più importante è sapere di non essere ok.
IMHO in un team che inizia a fare continuos integration credo che sia necessario un po' allenamento prima di cominciare a non fallire nemmeno una build.
Magari in futuro mi dovrò ricrede e darti ragione in toto ma adesso quello che vorrei ottenere dal build server è un primo passo per avere metriche ed informazioni sempre aggiornate sullo stato del mio progetto ed automatizzare tutte le operazioni ripetitive “post-commit”.
Per quanto riguarda la notifica con le lampade o sirena come suggerito nel tuo link è uno strumento un collega sta già realizzando, dai vuoi perderti la parte divertente! ;-)

# re: Re: Unit test e build server

Left by papo we(b)log at 29/06/2007 22:23
Gravatar

# Build server: prime impressioni

Left by makka at 21/08/2007 02:15
Gravatar
Build server: prime impressioni
Comments have been closed on this topic.