Copertura del codice Java in Hudson

Question

Sto migrando un paio di progetti da una formica a una maven. Il server di compilazione è e rimarrà Hudson.

Ho avuto problemi a registrare la copertura del codice in hudson con cobertura a causa dei eseguito e registrato due volte problema .

Il progetto è multi-modulo e sarebbe bello, anche se non necessario, avere un output aggregato dei dati di copertura del codice.

Tutto sommato, la soluzione che sto cercando deve:

• esegue test automatici per tutti i moduli e registra i risultati una volta ;
• mostra la copertura del codice del singolo modulo in Hudson ;
• può essere facilmente configurato una volta per l'intero progetto , non in tutti i moduli.

La soluzione può essere basata su Cobertura, o Emma o su qualsiasi altro strumento di copertura del codice java.

---

Aggiorna : l'esecuzione dei test con Emma duplica ancora i risultati e non esiste alcuna funzionalità merge , quindi non è realmente utilizzabile con build multi-modulo.

Answer 1

Sonar è uno strumento molto interessante che può essere facilmente integrato con Hudson, mi piace molto la sua organizzazione con multi- progetti di moduli. Dovresti provarlo

alt text http://sonar.codehaus.org/ wp-content / uploads / 2009/08 / dashboard.png

Answer 2

È un po 'hacker, ma l'approccio che sto usando è di usare un versione modificata del plugin Maven cobertura (che è disponibile dal loro repository ). Fornisce un target cobertura: generate-report, in modo da poter inserire cobertura: instrument e cobertura: generate-report nel ciclo di vita prima e dopo l'esecuzione dei test, rispettivamente. In questo modo otterrai i dati di copertura desiderati senza l'esecuzione / registrazione del test duplicato.

Il problema di fondo è che tutti i plug-in di copertura Maven non clover in cui mi sono imbattuto sono basati sull'idea di eseguire i test con copertura separatamente dall'esecuzione del test principale nel ciclo di vita di Maven. Ciò, ovviamente, si traduce in due serie di esecuzioni di test. Se stai usando un progetto freestyle, otterrai solo un set di test registrati (poiché, anche con due esecuzioni di test, c'è solo una copia dell'output di test), ma il tipo di progetto Maven intercetta effettivamente le esecuzioni di Maven mojo e registra l'output / i risultati del test al momento dell'esecuzione del test, piuttosto che tutti contemporaneamente alla fine della build, come fanno i progetti freestyle. Questo ha molti vantaggi, ma ha anche lo svantaggio piuttosto evidente che un singolo test eseguito due volte viene conteggiato come due test.

Detto questo, mentre ho visto argomenti forti per l'esecuzione di test sia sul codice non strumentale che su quello strumentato, preferisco eseguire i test una sola volta, rispetto al codice strumentato, non solo a causa dei problemi di Maven / Hudson, ma perché quando hai dei test che durano 45 minuti, sembra francamente sciocco eseguirli due volte per generare lo stesso risultato.

Answer 3

Robert,

Ho avuto anche questo problema e ho scoperto che Hudson non riporta due volte se si imposta il progetto come progetto freestyle piuttosto che come progetto Maven2. Perdi un po 'della gentilezza di avere un progetto maven2, ma per noi era un mestiere che dovevamo fare.

Jeff

Answer 4

Utilizziamo progetti in stile libero e non abbiamo questo problema, quindi, come indicato, questa potrebbe essere la fonte del tuo problema.

Per fornire le funzionalità di fusione, abbiamo creato il nostro repository di artefatti (non stiamo usando Maven). Alla fine di ogni build, copiamo il file cobertura.ser in una condivisione di rete, rinominandolo nel processo. Abbiamo un processo di visualizzazione consolidato che copia tutti i file di cobertura e file di codice sorgente (un altro artefatto di build copiato nella condivisione di rete) nella directory di build locale e genera il rapporto Cobertura.

La mancanza di un repository di artefatti standard all'interno di Hudson è un po 'frustrante, ma ha senso dare agli autori in genere l'uso di Maven per queste esigenze. Il nostro processo di compilazione viene eseguito su più server, quindi non possiamo semplicemente utilizzare percorsi relativi nelle altre directory dei lavori.

Nota, facciamo la stessa cosa per altre metriche: risultati dei test, JavaNCSS, ect. e si è unito utilizzando gli strumenti corretti o un codice personalizzato.

Usiamo lo stesso repository per artefatti di build tradizionali: DLL, JAR, script di installazione.

Answer 5

Vedi la copertura test Java SD per uno strumento ambientale estremamente basso con una bella interfaccia grafica. Non sono sicuro di aver capito il tuo "eseguire due volte" problema, ma se hai eseguito due volte (lo stesso deterministico) test con gli strumenti SD, otterrai gli stessi dati di copertura del test, ad esempio il suo idempotente. Se i test non sono deterministici, otterrai due diverse esecuzioni di test, ma questi strumenti uniscono facilmente i risultati di diverse esecuzioni in un unico riepilogo generale.

Gestiscono anche applicazioni estremamente grandi e gestiscono abbastanza bene più applicazioni thread (piccole schegge temporali possono rendere la risposta leggermente inaccurata in teoria, ma la pratica semplicemente non è un problema).

Answer 6

Hai considerato Atlassian's Clover ?

Il plugin maven-clover2 ha un nuovo obiettivo: clover2: setup che semplicemente strumentalizzerà i tuoi test senza biforcare il ciclo di vita o eseguendo i test due volte.

Definiresti gli obiettivi da percorrere in Hudson in questo modo:

mvn clover2:setup verify clover2:aggregate clover2:clover

Il plugin maven-clover2 è assolutamente gratuito da provare per 30 giorni.