Eclemma always reporting 0% of code coverage - java

I have a Maven test project for my application.
The JUnit tests run fine, and the code coverage test run too.
But the report always shows 0% of code coverage.
What should i do?

According to the official site, Eclemma is a code coverage plugin for Eclipse, based on JaCoCo library.
As you want to use the same code coverage engine outside eclipse, you should include the plugin Jacoco inside the Maven configuration (pom) of your project, as the following (this code was copied from the Agile Engineering blog):
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.6.0.201210061924</version>
<executions>
<execution>
<id>jacoco-initialize</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>jacoco-site</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
To run the tests just type the following on the command line tool:
mvn clean test
p.s.: you also could use other code coverage plugins like Cobertura or Emma.

Just in case you forgot to do these:
Are you annotating your tests using #Test?
Are you running the class as a JUnit test case or from the coverage button?
I'm not sure what the cause of the problem is, cause it always worked for me. Have you installed it from eclipse itself? Try to uninstall it, and reinstall from eclipse. Here's how to do it just in case:
In Eclipse, Click "Help" > "Install new Software"
Click "Add", and type the following:
Name: EclEmma (or any name you want)
Path: http://update.eclemma.org/
Select EclEmma, and install

Now I realized that you just want to get a report using the tool inside Eclipse...
How is the code coverage in the Eclipse Dialog? Did you tried to use the mouse right click on this dialog to export session (report), or inside File -> Export?

It's a known issue for many years and unfortunately there's no official solution yet for it.
You can see it here, here and here
One not-so-honey solution might be to try using eCobertura (or downgrading eclemma from 2.x to 1.x)

If you are using eclemma, you need to add jacoco dependency. if jacoco has been added and still, you are facing this issue, refer the eclemma faq: "Why does a class show as not covered although it has been executed?"
it says,
First make sure execution data has been collected. For this select the Sessions link on the top right corner of the HTML report and check whether the class in question is listed. If it is listed but not linked the class at execution time is a different class file. Make sure you're using the exact same class file at runtime as for report generation. Note that some tools (e.g. EJB containers, mocking frameworks ) might modify your class files at runtime.
So, Mockito / PowerMockito can cause this problem. In my case, I have added the class in #PrepareForTest(). I was shown that the test case was executed fine without errors but Jacoco did't improve the code coverage in its report.
Finally, removing the class from #PrepareForTest() annotation improved the code coverge. check if you have added it or not and remove it from annotation if added.

I just came across this issue and it was caused by an incorrectly configured classpath. When the unit tests were executed, they were executing against a compiled jar (actual source compiled outside of eclipse) and not my actual source code. After removing the jar from my classpath, the unit tests correctly hit my package source.

I was able to resolve the issue on mine by calling a instance of the class at the top of the test cases.
i.e.
public hotelOccupancy hotel = new hotelOccupancy();
#Test
public void testName() {
// some test here
}
Once I did that all my coverage began working and the issues were resolved.

I'm using eclemma 2.3.2 and it's working perfectly on eclipse
I only need to add these dependencies in my pom.xml
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<version>1.0.0.Alpha6</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<version>0.7.1.201405082137</version>
<scope>test</scope>
</dependency>
Then I build the project, update maven projects configuration and run coverage plugin as expected

Related

How can I run a program compiled by Maven?

I am starting to learn Maven by reading https://spring.io/guides/gs/maven/.
In the examples, after running mvn compile successfully, how can I run the program via maven? This part seems missing from the article.
Thanks.
You can invoke a Java program (i.e. with a public static void main(String[] args) signature) with the classpath of the combined dependencies for the current pom.xml using
mvn -q exec:java
You need to configure the main class to invoke in your pom.xml similar to
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.6.0</version>
<executions>
<execution>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>demo.Main</mainClass>
</configuration>
</plugin>
</plugins>
</build>
This is useful for testing and development, but not deployment
See http://www.mojohaus.org/exec-maven-plugin/usage.html for full details.
The Maven build process has a number of lifecycles, or points in the process. compile is one of the build steps, but most likely running the following would resolve your issue:
mvn clean package
This would generate a JAR file, in the folder where you ran it. You can then try running this JAR file using java.
Generally, maven is not used for running code. This is a build tool that you can use for compiling, running unit or integration tests, deploying you your code locally and remotely, etc..
It is based around the idea of a build lifecycle where which is in its turn is defined by a list of build phases. For example, the default lifecycle has the following phases:
validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package - take the compiled code and package it in its distributable format, such as a JAR.
verify - run any checks on results of integration tests to ensure quality criteria are met
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.
For more information you can refer to this.
UPDATE:
Having said that, it is possible as mentioned in Thorbjørn Ravn Andersen answer here.

How to use Cobertura with Cucumber jvm and Maven?

I am looking for the best way to measure code coverage for cucumber tests (cucumber jvm).
I found Cobertura but I don't really know how to use and configure it when it has to measure the code coverage for acceptance test and I can't find anything efficient to do that... (For the moment, I just added the maven plugin corresponding to Cobertura, but I don't know what configuration should be done inside).
Do you have any idea ?
If you think I should use any other tool than Cobertura, please tell me :)
Thank you
Before you try and use Cobertura, make sure you understand what it does and whether that applies to your case. Cobertura in fact IS a tool that measures the code coverage BUT it is important to understand how it does that.
Cobertura (and jcoverage which it's based on) calculate the percentage of the code covered by tests, meaning that it is actually checking what lines of code were touched! It is very different from the functional (or business domain) test coverage described by BDD tools like Cucumber that you are using.
Saying that, to use Cobertura you have 2 options:
Single run
Just include it in your dependencies in pom.xml and run: mvn
cobertura:cobertura
Integrate into Maven lifecycle
Add the plugin to your pom.xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.6</version>
<configuration>
<formats>
<format>html</format>
<format>xml</format>
</formats>
</configuration>
</plugin>
and run mvn clean site-deploy to execute the plugin.

Managing TestNg suite from Jenkins parameterized build

I'm running my tests in Jenkins and Maven and have different test suites in several TestNG.xml files.
Now I manage them directly in pom in this way:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire.version}</version>
<configuration>
<suiteXmlFiles>
<suiteXmlFile>Testing_Fuzzy_Logic.xml</suiteXmlFile>
<suiteXmlFile>Testing_ACL.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>
But I'd like to be able to select a specific test suite when start a Jenkins build. And I'd like all the suites to be included to the build as default if I did not select a specific one. So my question is:
What is the proper way to write all my TestNG.xml files in Jenkins parameters and send them to pom file to ask Maven use them when running tests?
Something like this:
Jenkins variable:
Set it to pom file somehow:
The issue has been solved by an example above. At first there was an error in file name and it confused me. I fixed it and my example works okay now.
So one of solutions is: a string TEST_NG_XML parameter which is added to parameterized Jenkins build. All test suites are set there and separated by comma by default. When needed, any of them can be removed (See examples above).
But if there are any other solutions, I'll be delighted to see them.
On jenkins, you can pass top level maven goals in following format
test -DargLine="-DTest_NG_XML=src/test/resources/testng.xml"
In this way , you are passing the value of your Test_NG_XML variable while running the maven test phase.In general execute following maven goal on jenkins.
-DargLine="-Dparameter=value"
test -DsuiteXmlFile=src/test/resources/testng1.xml,src/test/resources/testng2.xml
How can one be sure the precedence of execution of test suites passed this way?
I was facing the same issue, I have split it into separate Jenkins builds with each passing separate suite, to be absolutely sure certain suite runs before the other.
I would like to simplify it, possibly passing this way as indicated above... but did you try the order of execution? Thanks

How can I share clover coverage data between maven and IntelliJ

I have a multi-module maven project. I'm using intellij-idea as my IDE.
I have Maven configured with the clover plugin to automatically instrument on build.
How can I get IntelliJ to recognize those changes and refresh its coverage data.(NOTE: having to click the "Refresh Coverage" toolbar button is fine.)
I've tried configuring maven-clover2-plugin like so:
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-clover2-plugin</artifactId>
<version>3.2.2</version>
<configuration>
<baseDir>${project.basedir}</baseDir>
<cloverMergeDatabase>
${project.basedir}.clover\cloverMerge.db
</cloverMergeDatabase>
</configuration>
<executions>
<execution>
<id>main</id>
<phase>package</phase>
<goals>
<goal>instrument</goal>
<goal>aggregate</goal>
<goal>check</goal>
</goals>
</execution>
<execution>
<id>site</id>
<phase>pre-site</phase>
<goals>
<goal>instrument</goal>
<goal>aggregate</goal>
<goal>check</goal>
</goals>
</execution>
<execution>
<id>clean</id>
<phase>clean</phase>
<goals><goal>clean</goal></goals>
</execution>
</executions>
</plugin>
I then configured my project settings to use:
.clover\cloverMerge.db and checked the relative to project directory. checkbox.
But that didn't work.
NOTE:
At the bottom of Configuring Instrumentation it says
Do not set these locations explicitly if you have a multi-module project.
So I also tried leaving the location as the default for both Maven and IDEA and that didn't work either.
Also in the Clover for IDEA installation GUIDE - Known Issues
If you are using the Maven build tool, you should avoid using the same > IntelliJ output directory as Maven does. As Maven uses the target/classes and target/test-classes directories,
avoid specifying these ones. The clover.db location for IntelliJ should also be distinct from that used by Maven.
WHY should they be distinct is there some file corruption issue? If they're kept distinct then HOW can I get awesome coverage highlighting/etc, without having to repeat builds in a completely separate process?
Well I finally figured out an answer. I'm leaving this here for posterity.
The solution is complicated and somewhat of a Hack but it WORKS.
Update the parent projects pom.xml file
cloverDB: <cloverDatabase>${project.basedir}.clover\clover.db</cloverDatabase>
Merge CloverDB:
<cloverMergeDatabase>
${project.basedir}.clover\cloverMerge.db
</cloverMergeDatabase>
Create your Unit Tests to Run in IntelliJ IDEA
setup a Before launch - Run Maven Goal
clean clover2:setup prepare-package -DSkipTests
Create a Maven Run Configuration
Make the Unit-Tests a Before launch condition
In the command line have Maven run clover2:aggregrate
Update Intellij Project Settings for clover to point to the merge file
Make sure the Relative to project directory. checkbox is checked.
InitString to User specified with the value the same as your pom file.
in my case: .clover\cloverMergeDB
Once the command is run, just click the Referesh Coverage icon to see and work with the coverage data in idea.
If the tests fail you will also have the nice IntelliJ Test runner Tab to figure out why.
At the bottom of Configuring Instrumentation it says
Do not set these locations explicitly if you have a multi-module project.
Documentation actually says: Do not set these locations explicitly (using absolute path) if you have a multi-module project. The reason is simple - if you use an absolute path, then you will not have a separate clover.db for every module, but only a single clover.db file.
"If you are using the Maven build tool, you should avoid using the same IntelliJ output directory as Maven does. As Maven uses the target/classes and target/test-classes directories, avoid specifying these ones" [...] WHY should they be distinct is there some file corruption issue?
The problem is as follows: IntelliJ IDEA uses it's own engine to compile sources. It means that it does not have to call the original project's build system (a Maven, for instance) to compile sources.
It means that:
- if you have a Maven-based project and it has the Clover-for-Maven plugin installed and
- at the same time you have the Clover-for-IDEA installed in the IntelliJ IDE
- and these two Clover integrations use the same output folders for classes and databases
... then these two Clover integrations may start overwriting their files.
In most cases this is not a desired behaviour because any source code modification / project rebuild action etc in IDEA will trigger source recompilation; which can delete results obtained previously by Clover-for-Maven.

How to tell Maven2 to not test non-#Test-annotated classes in test source folder?

Just got a strange error. Working on project using JUnit and Maven 3.0.3 I've created in my test/src/java folder one test class - ClassifierUtilTest.java, with #Test-annotated methods and stuff, and two utility classes, just for the use in the testing env (one with few static methods for bypassing private visibility scopes and one mock for tested interface).
It works good under Maven 3.0.3 (mvn test), and in Eclipse 3.7 (run as / JUnit test), but when someone else tried to 'mvn test' it with Maven 2.2.1 it failed. Apparently it tried to treat those util classes as test classes and failed due to 'no #Test-annotated methods' and 'more than one constructor'.
It's not JUnit fault (at least it shouldn't be, maven dependency is the same, junit:junit:4.9), so it seems to be strictly maven or maven-surefire-plugin fault. I was wondering if there is some widely-known workaround for Maven 2.2.1 for this problem?
maven-surefire-plugin by default runs all the classes the have Test prefix or suffix (like yours ClassifierUtilTest) and TestCase suffix. Just change the name to ClassifierTestUtil and you'll be fine.
You can also exclude certain files/directories in pom.xml, see Inclusions and Exclusions of Tests:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.11</version>
<configuration>
<excludes>
<exclude>**/ClassifierUtilTest.java</exclude>
</excludes>
</configuration>
</plugin>

Categories

Resources