Develop Reference

Classes and methods not getting ignored in Jacoco coverage report

I wrote a custom annotation to ignore classes and methods while generating Jacoco coverage report. Please refer to code below:
#Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
public #interface ExcludeFromJacocoGeneratedReport {
}
This is working fine in my local but when I am running a Jenkins pipeline, classes and methods marked with this custom annotation are not getting ignored in Jacoco coverage report.
Please guide me if I have missed something or some explicit configuration is required before running jenkins pipeline in this case.

Jacoco - How to check which lines are missing coverage

I am using jacoco for Test coverage verification in a Java Library created with Gradle. I have set the verification rule to limit minimum coverage to 1.0 (100%). I have a few classes in my code which are not meeting the criteria. based on the unit-tests that I have written, I don't think I am missing any line of code.
on those lines, I was wondering if there is a was to make jacoco print out which lines are not getting covered by unit tests during the build process?
currently jacoco causes a build failure reporting the coverage ration for each files that didn't meet the bar but it does not provide any information on specific lines that were not covered.

I was able to configure My Gradle-Groovy project to start generating Jacoco coverage reports by doing the following:
added jacoco plugin to buildscript in build.gradle
apply plugin: 'jacoco'
adding a custom configuration:
jacocoTestReport {
dependsOn test
}
chaining jacocoTestReport to your test task
test {
finalizedBy jacocoTestReport
}
This ensures, report is always generated after tests run.
Note: if you have added both jacoco and java plugin, reports are automatically generated and stored at $buildDir/reports/jacoco/test in such a scenario, you can skip above steps.

How to give test coverage for private constructor of a final class in sonarqube?

I have a util class which is final and I have added one private constructor for hide the default public one. How I can get the coverage for this class in sonarqube with jacoco coverage report and build in Jenkins?
public final class Util {
// My contructor
private Util() {
super();
}
}

According to JaCoCo changelog such private empty no-argument constructors are automatically filtered out starting from JaCoCo version 0.8.0. Changelog also notes:
Tools that directly read exec files and embed JaCoCo for this (such as SonarQube or Jenkins) will provide filtering functionality only after they updated to this version of JaCoCo.
Announcement of release of JaCoCo version 0.8.0 states:
Tools that directly read exec files (which is not a final report) and embed JaCoCo for generation of report will provide filtering functionality only after they updated to this version of JaCoCo.
So please follow/wait/etc respective vendors such as
SonarQube - https://jira.sonarsource.com/browse/SONARJAVA-2608
Eclipse EclEmma - https://bugs.eclipse.org/bugs/show_bug.cgi?id=529391
Jenkins - https://github.com/jenkinsci/jacoco-plugin
Reports generated by corresponding version (0.8.0) of integrations developed as part of JaCoCo project by us (Ant Tasks, Maven Plugin and Command Line Interface) provide filtering functionality.
As of today (30 Jan 2018):
update for SonarQube (https://jira.sonarsource.com/browse/SONARJAVA-2608) is supposed to be in not yet released SonarJava plugin version 5.1
update for Jenkins Plugin (https://github.com/jenkinsci/jacoco-plugin/commit/d04b50962a022b615d5085271f1696d9f6080198) is committed but also not yet released

If you configure sonar to use cobertura (and not jacoco) for the code coverage, you could simply exclude that method from code coverage.
That seems easier than writing an artifical test case using reflection.

Gradle jacoco multi project. How to output the code coverage of all the project in the terminal?

I am using Gradle jacoco plugin and have JUnit tests in a gradle multi project.
I have installed jacoco in order to report to sonarqube my code coverage, which I did.
Gitlab-CI also offer a badge for the code coverage, I only need to output the code coverage in a terminal and use a regex to find it.
Is there a way to output the code coverage of all the project in the terminal ?

Yes, you can. Possible ways:
1) Use Gradle plugin gradle-console-reporter to report various kinds of summaries to console. JUnit, JaCoCo and Cobertura reports are supported.
In your case, following output will be printed to console:
...
BUILD SUCCESSFUL
Total time: 4.912 secs
Coverage summary:
project1: 72.2%
project2-with-long-name: 44.4%
Then you can use coverage with regular expression in Gitlab's .gitlab-ci.yml to parse code coverage.
2) Second option is a little bit tricky. You can print full JaCoCo HTML report (e.g. using cat target/site/jacoco/index.html) and then use regular expression (see this post) or grep (see this post) to parse coverage.

AFAIK Gradle does not support this, each project is treated separately.
To support your use case some aggregation task can be created to parse a report and to update some value at root project and finally print that value to stdout.
Update with approximate code for solution:
subprojects {
task aggregateCoverage {
// parse report from each module into ext.currentCoverage
rootProject.ext.coverage += currentCoverage
}
}

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.