Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Windows XP, maven 2.0.8
    • Testcase included:
      yes
    • Patch Submitted:
      Yes
    • Number of attachments :
      5

      Description

      In my project, I have both unit tests ("test" phase) and integration tests ("integration-test" phase).
      So far I could manage configuring maven-surefire-plugin and maven-surefire-report-plugin to execute both tests correctly and also generate 2 different reports.
      Then I have added cobertura-maven-plugin to the reporting in order to get coverage but unfortunately only unit tests have their coverage reported (I know it because I have some classes which are only integration tested but are reported as 0% covered).
      After trying to find information on the mailing lists, on the web and other existing resources, I could not find any hint on how to make this work.
      It looks like cobertura-maven-plugin, by its current design, will never run integration-test to collect coverage, it seems to stop at the "test" phase.

      Thus whenever a POM project has integration tests and uses cobertura-maven-plugin for coverage report, the generated reports are wrong, which is very misleading.

      Actually, I was surprised not to find this issue already in JIRA.

      Is there a chance this gets fixed soon? Or is there a usable workaround for this problem (besides switching to clover which I am not sure it would work better ) Did someone succeed in patching cobertura-maven-plugin to get the correct behavior?

        Issue Links

          Activity

          Hide
          Harald Brabenetz added a comment -

          I use the following workaround:

          <profile>
            <!-- Build with IntegrationTestcoverage => instrument classes with cobertura before integrationtests starts. -->
            <id>buildWithIntegrationTestCoverage</id>
            <activation>
              <property>
                <name>buildWithIntegrationTestCoverage</name>
                <value>true</value>
              </property>
            </activation>
            <build>
              <plugins>
                <plugin>
                  <groupId>org.codehaus.mojo</groupId>
                  <artifactId>cobertura-maven-plugin</artifactId>
                  <version>2.3</version>
                  <executions>
                    <execution>
                      <id>instrument-classes</id>
                      <phase>package</phase>
                      <goals>
                        <goal>instrument</goal>
                      </goals>
                    </execution>
                  </executions>
                </plugin>
              
                <!-- Add cobertura as dependency to the jetty-plugin (required for instrumented classes) -->
                <plugin>
                  <groupId>org.mortbay.jetty</groupId>
                  <artifactId>maven-jetty-plugin</artifactId>
                  <dependencies>
                    <dependency>
                      <groupId>org.codehaus.mojo</groupId>
                      <artifactId>cobertura-maven-plugin</artifactId>
                      <version>2.3</version>
                      <type>jar</type>
                    </dependency>
                  </dependencies>
                </plugin>
              </plugins>
            </build>
          </profile>
          

          And then i start the site-generation with:

          mvn clean install site -DbuildWithIntegrationTestCoverage=true
          
          Show
          Harald Brabenetz added a comment - I use the following workaround: <profile> <!-- Build with IntegrationTestcoverage => instrument classes with cobertura before integrationtests starts. --> <id>buildWithIntegrationTestCoverage</id> <activation> <property> <name>buildWithIntegrationTestCoverage</name> <value>true</value> </property> </activation> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> <version>2.3</version> <executions> <execution> <id>instrument-classes</id> <phase>package</phase> <goals> <goal>instrument</goal> </goals> </execution> </executions> </plugin> <!-- Add cobertura as dependency to the jetty-plugin (required for instrumented classes) --> <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <dependencies> <dependency> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> <version>2.3</version> <type>jar</type> </dependency> </dependencies> </plugin> </plugins> </build> </profile> And then i start the site-generation with: mvn clean install site -DbuildWithIntegrationTestCoverage=true
          Hide
          Miguel Almeida added a comment -

          Is there any news on this?

          There are a couple of patches here, and there's even a fork at http://code.google.com/p/cobertura-it-maven-plugin/wiki/HowToUse to solve this issue.

          Can any of it be used to implement this feature?

          Show
          Miguel Almeida added a comment - Is there any news on this? There are a couple of patches here, and there's even a fork at http://code.google.com/p/cobertura-it-maven-plugin/wiki/HowToUse to solve this issue. Can any of it be used to implement this feature?
          Hide
          Robert Scholte added a comment -

          It seems like Jira is not the right tool to come to a solid/everything covering solution.
          So I've started a confluence-page: http://docs.codehaus.org/display/MOJO/Cobertura+Maven+Plugin
          This is quite a complex issue and is related to other cobertura-issues.
          So let's first describe how the plugin should work.
          Any contribution is appreciated.

          Show
          Robert Scholte added a comment - It seems like Jira is not the right tool to come to a solid/everything covering solution. So I've started a confluence-page: http://docs.codehaus.org/display/MOJO/Cobertura+Maven+Plugin This is quite a complex issue and is related to other cobertura-issues. So let's first describe how the plugin should work. Any contribution is appreciated.
          Hide
          Steven Swor added a comment -

          Codehaus' instance of Confluence does not allow public registration, so even though I'd like to weigh in on this discussion, I am unable to do so there. May I suggest we keep this in JIRA so that cobertura plugin users are able to contribute their suggestions as well?

          Show
          Steven Swor added a comment - Codehaus' instance of Confluence does not allow public registration, so even though I'd like to weigh in on this discussion, I am unable to do so there. May I suggest we keep this in JIRA so that cobertura plugin users are able to contribute their suggestions as well?
          Hide
          Steven Swor added a comment -

          The cobertura-lifecycle has to be extended, and I think it should look something like this:

          Before entering the test phase, the java-classes need to be instrumented for test
          Before entering the integration-test phase, java-classes need to be instrumented for integration-test.
          Now they both have their own .ser file, and during verify all these should be checked and eventually reported.
          I think this would result in less configuration and no need to misuse a report-only goal.

          This sounds like a reasonable approach. What sort of work would be involved in implementing this solution?

          Show
          Steven Swor added a comment - The cobertura-lifecycle has to be extended, and I think it should look something like this: Before entering the test phase, the java-classes need to be instrumented for test Before entering the integration-test phase, java-classes need to be instrumented for integration-test. Now they both have their own .ser file, and during verify all these should be checked and eventually reported. I think this would result in less configuration and no need to misuse a report-only goal. This sounds like a reasonable approach. What sort of work would be involved in implementing this solution?

            People

            • Assignee:
              Robert Scholte
              Reporter:
              Jean-Francois Poilpret
            • Votes:
              71 Vote for this issue
              Watchers:
              56 Start watching this issue

              Dates

              • Created:
                Updated: