Develop Reference

Jacoco Code Coverage - Some classes not appearing in report

I am using maven jacoco pugin to generate code coverage report. I am using Powermock for my Junits. I am getting this message at the time of build:
Classes in bundle "XYZ" do not match with execution data. For report generation, same class files must be used at runtime.
[WARNING] Execution data for class "com/abc/example/testEmail" does not match
...
As per my analysis,wherever I have used #PrepareForTest on a particular class, that class is not showing up in the code coverage report.
I am using the following version of Jacoco and Powermock:
Jacoco - 0.7.9
PowerMock - 1.7.1

Running Clover coverage reporter inserts new column to CSV test and breaks build

I am trying to integrate Clover with a Java project at work. Clover has been added to the classpath, the plugin has been added to the POM and the license has been set up.
When I run mvn clean clover:setup test clover:aggregate clover:clover Clover starts up correctly. However, tests that generate csv's fail because the CSV output is not what is expected. This is what gets generated for one of the tests:
<ID,NAME,[__CLR4_1_2_TEST_NAME_SNIFFER,"DESCRIPTION,Long","DESCRIPTION,Short",country
001,Fred,com_atlassian_clover.TestNameSniffer$1#e628ccb,Mr. Fred Flinstone,Fred Flinstone,US
002,Bob,com_atlassian_clover.TestNameSniffer$1#e628ccb,Mr. Bob the builder,Bob the builder,UK
003,Tintin,com_atlassian_clover.TestNameSniffer$1#e628ccb,Mr. Tin Tin,Tin Tin,FR
004,,com_atlassian_clover.TestNameSniffer$1#e628ccb,,Rob the Bob,
005,,com_atlassian_clover.TestNameSniffer$1#e628ccb],,Tom the Bob,
>
This is what is expected:
<ID,NAME,["DESCRIPTION,Long","DESCRIPTION,Short",country
001,Fred,Mr. Fred Flinstone,Fred Flinstone,US
002,Bob,Mr. Bob the builder,Bob the builder,UK
003,Tintin,Mr. Tin Tin,Tin Tin,FR
004,,,Rob the Bob,
005,],,Tom the Bob,
Why would Clover add a new column in to the CSV output, is it possible to stop it? I'm using maven 3.3, JDK 8 and Clover version 4.0.2.
I have tried looking for an answer but cannot seem to find anything similar to this issue. When I remove the failing tests Clover works fine.

I'm pretty sure it's connected to the code (or a library) you're using to create that CSV file. Clover on its own won't modify a CSV file. I suppose there's a code which access Java Object fields by reflection. Since class is instrumented by Clover, it adds some instrumentation code (like CLV_TEST_SNIFFER.
There are basically two solutions to your problem:
Modify the code which dumps classes to CSV to exclude static class members (this will effectively exclude Clover objects). Anyway, I believe it's not desired to dump static members to CSV which, as I assume, is a data projection of your Java object (static members don't belong to object but to class). Though, I don't know your full use case, so I may be simply wrong.
You can simply exclude files which cause problems (the ones which are serialised to CSV?) from Clover instrumentation, effectively you'll loose coverage data for those classes.

SonarQube coverage missing some lines covered by Jacoco report

When I run unit tests with Jacoco agent, there is some discrepancy between my local Jacoco report and the coverage on SonarQube. This seems to only be affecting files that contain nested classes. The report generated locally has coverage information for the outer class and all inner classes, but the coverage data on SonarQube only includes the inner classes.
For example, Foo.java contains outer class, Foo, and inner classes, Bar and Baz.
My local report shows instruction coverage of 26% for class Foo, 46% for class Foo.Bar, and 0% for class Foo.Baz; the overall instruction coverage for Foo.java is 30%.
The SonarQube coverage page gives line coverage of 15% for Foo.java. I understand that line coverage does not equal instruction coverage, but I would expect the numbers to be closer. Upon further inspection, I noticed that in the file-based coverage view of Foo.java on SonarQube, all lines in the outer class Foo are marked "Not covered by unit tests" and the only lines that are marked covered are the ones in Foo.Bar that I expected. This difference makes up the approximately 15% gap between the Jacoco report and SonarQube. I don't see any exceptions in the local scanner logs or the server analysis logs.
I am running with JaCoCo 0.7.7.201606060606, Java version 1.8.0_73, and sonar-scanner 2.8 locally. The server is running Java version 1.8.0_66-b17, SonarQube version 5.6.3, and SonarQube Java plugin version 4.2.1.6971.
I would appreciate any suggestions and would be happy to provide more details if that would be helpful.

Comparison of "instructions" with anything else is like comparison of apples and oranges - they don't represent the same thing. Single line of code usually contains many bytecode instructions. And so it is wrong to expect "instruction coverage" to be close to "line coverage", for example: if in total you have 100 instructions in 10 lines and cover 1 line with 20 instructions, then missed instructions 80%, but missed lines 90%.
See http://www.eclemma.org/jacoco/trunk/doc/counters.html about counters that JaCoCo provides. And http://docs.sonarqube.org/display/SONAR/Metric+Definitions about what SonarQube shows. Instructions coverage is presented only in JaCoCo.
And not clear from your question if you see difference between covered lines in Foo.java shown by SonarQube and shown by JaCoCo. If so, then please provide screenshot.

It turns out that the class files that used to run the unit tests (which are also used to generate my local report) differ from the ones used by sonar-scanner. This is because after compilation, unit tests, and local report generation, bnd is run over the class files and rewrites the class files of #Component classes. Because sonar-scanner is run after bnd, it sees different class files. It seems like my problem wasn't inner vs. outer classes, but rather OSGi components vs. non-components; class Foo is an OSGi component, and the inner classes are not.
When I run the scanner over the same classes files used by the Jacoco agent, the line coverage of Foo.java reported by SonarQube is 27% (instead of 15%), and the file-based coverage view matches my local report.

How to detect unused step definitions in cucumber-jvm junit project?

I'm running automation tests using cucumber-junit project and i've roughly around 200 scenario's in my project.. now the problem is, it's hard to find unused step definitions in my project as we constantly need to update features.. Is there any solution to detect step definitions that is no longer useful.. Any help much appreciated!!

Since cucumber-jvm 4.4.0 it is possible to use cucumber-jvm built in plugin - unused.
for cucumber junit runner it could look like this:
#RunWith(Cucumber.class)
#CucumberOptions(
plugin = {
"json:build/report/cucumber.json",
"unused:build/report/usage.txt"} //mind this plugin
glue = "stepdefs",
features = "features"
)
public class CucumberRunner {
}
After run unused stepdefs should be found in build/report/usage.txt
Original pull request: https://github.com/cucumber/cucumber-jvm/pull/1648

There can be a case where a single step can be a part of different scenarios and will have single method only in step definition. So, It is easy to map the feature file's step with the corresponding method while executing the feature file using 'cucumber feature' pulg-in.
However, It is literally not possible to cross validate the same from step definition file to identify the single step in number of feature files.
Perhaps, The only possible way out is to design your application in modular way:
1) with feature files and corresponding step definition files specific to a specific feature/module.
2) Keep generic methods in a generic parent step definition file.
Thus, Designing the application in a modular way can easily lead you to identify the unused methods that can be removed from the step definitions.

IntelliJ's cucumber plugin can search for usages of a step definition. It will not give you all unused ones in one go, but at least you can check individual usages one by one. The plugin is also available in the Community Edition of IDEA.

Cobertura unable to instrument java Interfaces

I am using Cobertura for code coverage of my Java code using maven. When the reports are generated, I found out that there is no coverage generated for Interfaces.java.
While going through the logs, I found below:
[cobertura] INFO [main]
net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does
not contain instrumentation information for the file
com/example/Interface.java. Ensure this class was instrumented, and
this data file contains the instrumentation information.
[file name mocked up]
Please let me know the reason for this. How can I have code coverage for interfaces in java.
Thanks

As commented by Tassos Bassoukos, Interfaces don't have any code, thus there is no possibility of instrumentation. Instead, instrument all classes that implement that interface.
So, cobertura will not be able to show code coverage for interfaces, and skip the interfaces.java files.