Come posso ottenere Emma o Cobertura, con Maven, per segnalare la copertura del codice sorgente in altri moduli?

Question

Ho una configurazione Maven multi-modulo con codice Java.

La mia unità testa, in uno dei moduli, il codice di esercizio in più moduli. Naturalmente, i moduli hanno interdipendenze e il codice in tutti i moduli rilevanti viene compilato secondo necessità prima dell'esecuzione del test.

Quindi: come posso ottenere un rapporto sulla copertura dell'intero codebase?

---

Nota: non sto chiedendo come combinare i risultati della copertura per i test in più moduli. Sto chiedendo come ottenere la copertura per i test in un singolo modulo usando il codice strumentato da più moduli. Chiunque fosse interessato al primo potrebbe fare riferimento a theseotherquestions e alle raccomandazioni di Crowne per Maven Dashboard e Sonar.

Sono riuscito a ottenere un rapporto di copertura completo using pure Ant. [EDIT:] Ho strumentato tutti i jar dalla directory di sviluppo-runtime in una directory temporanea; anteposto la directory temporanea al classpath; quindi eseguito i test da Ant con il test batch .

Ant può essere eseguito da Maven, ma la sfida qui è l'integrazione senza soluzione di continuità (cioè, l'alimentazione automatica di tutti gli elementi classpath e sourcepath da Maven a Ant automaticamente), motivo per cui non ho usato le strutture di Maven per questo scopo.

Ci sono anche otherquestions sui test di integrazione. Tuttavia, per impostazione predefinita, il report di ciascun progetto per impostazione predefinita riporta solo la copertura del codice nello stesso progetto , mentre i miei test eseguono il codice in più progetti.

Questo article in Spanish potrebbe essere rilevante. Ecco un altro Seam-specific article.

---

Answer 1

Questo recent blog post by Thomas Sundberg contiene un metodo che risolve parzialmente il problema utilizzando formica per le chiamate COBERTURA, invece di utilizzare il plugin Maven cobertura.

si basa sul seguente approccio di base con i file pom.xml e build.xml specializzati:

Inizia con un esperto di tipica compilare sul POM genitore, che compila tutte le classi nei moduli bambino.

mvn clean compile # maven-compile-plugin called for compiling 

Poi strumento tutte le classi del modulo:

ant instrument # cobertura called for instrumentation 

quindi chiamare l'esperto-infallibile-plugin chiamato per il test utilizzando le classi strumentate, con cobertura come dipendenza di prova

mvn test 

Quindi utilizzare una chiamata report personalizzata per inserire tutti i risultati da diversi moduli:

ant report # cobertura called for reporting 

Gli elementi chiave del file ant build.xml sono di strumentare tutti i moduli separatamente e quindi di riportare su tutti i moduli dopo aver unito i risultati. Questa funzione deve essere chiamato per ogni modulo nel suo esempio:

<target name="instrumentAModule"> 
    <property name="classes.dir" value="target/classes"/> 
    <cobertura-instrument todir="./${module}/${classes.dir}"> 
     <fileset dir="./${module}/target/classes"> 
      <include name="**/*.class"/> 
     </fileset> 
    </cobertura-instrument> 
</target> 

Poi, dopo il test è completo, la fase di rendicontazione si fonde prima tutti i risultati di tutte le diverse directory vengono fuse in un nuovo file .ser (chiamato sum.ser nel suo esempio)

<target name="report" depends="merge"> 
    <property name="src.dir" value="src/main/java/"/> 
    <cobertura-report datafile="sum.ser" 
         format="html" 
         destdir="./target/report"> 
     <!-- Add all modules that should be included below --> 
     <!-- fileset dir="./MODULE_NAME_TO_REPLACE/${src.dir}"/ --> 
     <fileset dir="./product/${src.dir}"/> 
    </cobertura-report> 
</target> 

<target name="merge"> 
    <cobertura-merge datafile="sum.ser"> 
     <fileset dir="."> 
      <include name="**/cobertura.ser"/> 
     </fileset> 
    </cobertura-merge> 
</target> 

può essere possibile integrare i componenti della formica in Maven utilizzando il plugin antrun, ma non sono abbastanza familiarità con le fasi/cicli di vita per sapere dove mettere le diverse chiamate.

Questo è molto utile per me, poiché scrivo classi di test astratte nei miei moduli API e quindi fornisco loro un'implementazione nei miei moduli lib. Finora sia la cobertura che Emma non sono state in grado di gestire questo progetto, quindi la copertura del mio codice è in genere 0 o nelle singole cifre.

Answer 2

Dubito che sarebbe possibile in quanto le informazioni di copertura si ottiene cobertura/Emma di strumentazione le classi compilate. Mentre ciò funzionerebbe per le classi nel progetto specificato, è dubbio che questi strumenti possano strumentare le librerie dipendenti.

Anche uno sguardo allo maven cobertura plugin usage non sembra indicare alcuna possibilità.

Answer 3

ho trovato questo abbastanza semplice (anche se ho fatto qualche tempo fa, e può essere arrugginito con i dettagli ...

Il mio progetto principale contiene tutti i moduli. Io uso Cobertura per misurare la mia copertura di test. I Sto usando Hudson come un motore di Continuous Integration, e hanno il plugin Cobertura per Hudson.

e ha lavorato un piacere per un po 'di tempo.

Good Luck!

Answer 4

In generale, i rapporti si riferiscono a loro modulo specifico, ma possono essere aggregati,
due approcci sono:

• maven-dashboard-plugin
• sonar

io vi consiglio di provare a utilizzare il sonar per fare l'aggregazione dei report per te.

Vedere l'istanza pubblica "nemo", per vedere le straordinarie funzionalità offerte.

Answer 5

Non ha mai fatto, ma questo può essere un modo per realizzarlo:

• In ogni modulo, poco prima della installazione fase, diamo strumento cobertura i file JAR e installare i file jar di strumentazione (!) nel repository Maven locale
• Nel modulo dei test, Maven utilizzerà le dipendenze artefatto dal repository Maven locale per eseguire i test. Queste classi strumentate dovrebbero ora apparire nel file di dati, ad es. cobertura.ser
• Eseguire la generazione di report di cobertura come al solito dal modulo di test del progetto, ad es. mvn site

Vedi cobertura documentazione su come richiamare manualmente cobertura al file JAR esterno dello strumento sul posto:

... È inoltre possibile passare in file jar da strumentato usando i set di file di formiche standard. Cobertura estrae ogni classe dal barattolo e la strumenta. Se 'adir' non è stato specificato, allora l'vaso originale verrà sovrascritto con una versione strumentato ...

Il pom.xml 's costruire plugin può apparire come questo - si consiglia di aggiungere un profilo o utilizzare classificatori per distinguere tra il file jar finale e il file jar strumentato se non si desidera sovrascriverli nel repository locale. Quindi, nel modulo dei test, è sufficiente definire le dipendenze degli altri moduli utilizzando i classificatori.

 <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-antrun-plugin</artifactId> 
      <executions> 
       <execution> 
        <id>cobertura-inplace-instrumentation</id> 
        <phase>package</phase> 
        <configuration> 
         <tasks> 
          <taskdef classpathref="maven.plugin.classpath" resource="tasks.properties" /> 
          <cobertura-instrument 
           datafile="${project.build.directory}/cobertura-nop.ser"> 
           <fileset dir="${project.build.directory}"> 
            <include name="${project.build.finalName}.${project.packaging}" /> 
           </fileset> 
          </cobertura-instrument> 
         </tasks> 
        </configuration> 
        <goals> 
         <goal>run</goal> 
        </goals> 
       </execution> 
      </executions> 
      <dependencies> 
       <dependency> 
        <groupId>net.sourceforge.cobertura</groupId> 
        <artifactId>cobertura</artifactId> 
        <version>1.9.4.1</version> 
       </dependency> 
      </dependencies> 
     </plugin>