W jaki sposób sprawić, by Emma lub Cobertura wraz z Maven informowały o kodzie źródłowym w innych modułach?

Question

Mam wielomodułową konfigurację Maven z kodem Java.

Moja jednostka testuje, w jednym z modułów, kod ćwiczenia w wielu modułach. Oczywiście, moduły mają współzależności, a kod we wszystkich odpowiednich modułach jest kompilowany w razie potrzeby przed wykonaniem testu.

Więc: Jak mogę uzyskać raport na temat zasięgu całej bazy kodów?

---

Uwaga: Nie pytam, jak połączyć wyniki pokrycia testami w wielu modułach. Pytam, jak uzyskać pokrycie dla testów w jednym module przy użyciu oprzyrządowanego kodu z wielu modułów. Każdy zainteresowany tym pierwszym może odnosić się do theseotherquestions, a także zaleceń Crowne'a dotyczących Maven Dashboard i Sonar.

Udało mi się uzyskać pełny raport pokrycia using pure Ant. [EDYTOWANIE:] I oprzyrządowania wszystkie słoiki z katalogu dewelopersko-runtime do katalogu tymczasowego; poprzedził katalog tymczasowy ścieżką klas; następnie przeprowadzono test z Ant z testem wsadowym .

Mrówka może być uruchamiana z Mavena, ale wyzwaniem jest tutaj bezproblemowa integracja (tj. Automatyczne przekazywanie wszystkich elementów ścieżki klas i ścieżek z Maven do Ant), dlatego nie używałam do tego celu urządzeń Mavena.

Istnieje również otherquestions o testach integracyjnych. Jednak domyślnie raport każdego projektu domyślnie raportuje tylko pokrycie kodu w projekcie z tym samym, podczas gdy moje testy kodu wykonują wiele projektów.

Ta article in Spanish może być odpowiednia. Oto kolejny Seam-specific article.

---

Answer 1

Ten recent blog post by Thomas Sundberg zawiera metodę, która częściowo rozwiązuje ten problem za pomocą mrówka dla połączeń Cobertura, zamiast za pomocą wtyczki maven cobertura.

Opiera się ona na następującej podstawowej podejścia z wyspecjalizowanymi pom.xml i build.xml pliki:

zacząć od typowego Maven skompilować na pom nadrzędnej, która gromadzi wszystkie zajęcia w modułach podrzędnych.

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

Następnie przyrząd wszystkie klasy modułów:

ant instrument # cobertura called for instrumentation 

Następnie wywołać maven-surefire-plugin o nazwie do testowania za pomocą oprzyrządowanego zajęcia z Cobertura jako zależność testowym

mvn test 

Następnie użyj niestandardowego połączenia z raportem, aby pobrać wszystkie wyniki z różnych modułów:

ant report # cobertura called for reporting 

Kluczowymi elementami pliku ant build.xml są instrumentacja wszystkich modułów osobno, a następnie raportowanie wszystkich modułów po scaleniu wyników. Funkcja ta musi być wywołana dla każdego modułu w jego przykład:

<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> 

Następnie po zakończeniu testowania fazę raportowania pierwszy scala wszystkie wyniki z wszystkich różnych katalogów są połączone w nowym pliku .ser (zwanego sum.ser w swoim przykładzie)

<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> 

może istnieć możliwość zintegrowania mrówka komponenty do Maven za pomocą wtyczki antrun, ale nie jestem na tyle obeznany z fazami cyklu życia/wiedzieć, gdzie umieścić poszczególne połączenia.

Jest to bardzo przydatne dla mnie, ponieważ piszę abstrakcyjne klasy testowe w moich modułach API, a następnie dostarczam im implementację w moich modułach lib. Do tej pory zarówno kobertura, jak i emma nie były w stanie obsłużyć tego projektu, więc mój zasięg kodu wynosi zazwyczaj 0 lub w pojedynczych cyfrach.

Answer 2

Wątpię, by było to możliwe, ponieważ informacje o zasięgu są uzyskiwane przez cobertura/emma przez oprzyrządowanie skompilowanych klas. Chociaż będzie to działać w przypadku klas w określonym projekcie, wątpliwe jest, czy te narzędzia będą bibliotekami zależnymi od przyrządów.

Spojrzenie na maven cobertura plugin usage również nie wydaje się wskazywać na taką możliwość.

Answer 3

Znalazłem to całkiem proste (chociaż ja go jakiś czas temu i może być zardzewiały ze szczegółami ...

Mój rdzeń projekt zawiera wszystkie moduły. Używam Cobertura zmierzyć mój pokrycia testowego. I jestem przy użyciu Hudson jako Continuous Integration silnika i mieć wtyczki cobertura dla Hudson.

on pracuje uczta na chwilę teraz.

Powodzenia!

Answer 4

Generalnie raporty odnoszą się do ich konkretnego modułu, jednakże mogą one być łączone,
dwa podejścia są:

• maven-dashboard-plugin
• sonar

Polecam wypróbowanie użyciu sonaru zrobić dla ciebie agregację raportów.

Zobacz ich publiczne wystąpienie "nemo", aby zobaczyć imponujące możliwości, jakie są oferowane.

Answer 5

Nigdy nie próbowałem, ale to może być drogą do osiągnięcia go:

• W każdym module, tuż przed zainstalować fazę, pozwól instrumentowi Cobertura pliki jar i zainstalować oprzyrządowanego pliki jar (!) do lokalnego repozytorium Maven
• W module testowym Maven użyje zależności artefaktów z lokalnego repozytorium Maven, aby uruchomić testy. Te oprzyrządowane klasy powinny teraz pojawiać się w pliku danych, np. cobertura.ser
• Generuj generację raportu kobertura jak zwykle z modułu testów twojego projektu, np. mvn site

Zobacz cobertura dokumentację na temat sposobu ręcznego wywołania Cobertura do instrumentów zewnętrznych plików JAR w miejscu:

... Można również przekazać w plikach jar być oprzyrządowanie używając standardowych zestawów plików Ant. Cobertura wydobywa każdą klasę ze słoika i instrumentuje ją. Jeśli „todir” nie została określona wtedy oryginalny słoik zostaną nadpisane oprzyrządowanego wersji ...

pom.xml „s budować wtyczek może wyglądać tak - możesz dodać profil lub zastosowania klasyfikatorów aby odróżnić ostateczny plik jar od oprzyrządowanego pliku jar, jeśli nie chcesz go zastąpić w lokalnym repozytorium. Następnie, w module testów, wystarczy zdefiniować zależności z innymi modułami za pomocą klasyfikatorów.

 <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>