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.

Pitest gradle, low coverage due to #Data

I tried to get a good coverage file in my java spring project, I mean; see where my tests are good and where they are not. But my problem is that #Data generate a lot of function/class that I don't want to test, and just ruin my coverage.
I already search for a solution, but there is nothing to fix my problem. Looks like Jacoco have something to fix my problem but not Pitest. Maybe Im just not taking the problem right.

Since version 1.2.1 Pitest ignores any method or class annotated with Generated.
You can configure Lombok to add the annotation by adding the following in lombok.config :
lombok.addLombokGeneratedAnnotation = true

Testing Lombok annotations with Junit

I have a simple Java program which uses the Lombok Annotation - #Builder.
I am testing my code using junit and everytime I run my unit tests, my coverage is always below 50% inspite of the fact that I am testing my entire code.
I looked into the junit generated code coverage and I saw that it was the Lombok annotation which was making the coverage drop.
I see something like:
toString() - 0%
build() - 0%
MyMethod.MyMethodBuilder() - 0%
How do I test these methods for the #Builder annotation? Or the only way to improve coverage is to exclude those from the test coverage?

Starting JaCoCo v0.8.0, you should create lombok.config file to the root of your project and add following content to it:
lombok.addLombokGeneratedAnnotation = true
This will add #Generated annotation to Lombok generated files and JaCoCo will know that code coverage of such a code should be ignored.
Credits to original author here

Create lombok.config file and add texts below:
config.stopBubbling = true
lombok.addLombokGeneratedAnnotation = true
config.stopBubbling = true is telling Lombok that this is the root directory and that it shouldn’t search parent directories for more configuration files (you can have more than one lombok config files in different directories/packages).
lombok.addLombokGeneratedAnnotation = true is telling Lombok to add the #lombok.Generated annotation to all generated methods.

Decompile class which contains lombok annotation to see how lombok has generated source code and then write junits considering that code.
e.g. In case of #ToString, make explicit call to toString method on class object i.e. obj.toString();

Better to use pl.pojo library to test the pojo model classes.

Sonarqube test case rule does not take #Test annotation into account

Sonarqube generates issues as
TestCases should contain tests
regarding that test classes does not have any tests inside but there are methods marked with #Test annotation and classes annotated with #RunWith(SpringJunit4ClassRunner.class).
I have no problem running TestSuites and importing unit test and coverage reports into sonarqube. I checked sonarqube source code and it should find annotations but unfortunately it does not. Rule id for the mentioned issue is S2187.
Is there a configuration for this rule to find annotated methods or is a known issue?
Edit - config:
sonar.projectKey=x
sonar.projectName=x
sonar.projectVersion=1.0
sonar.modules=a,b,c
a.sonar.projectBaseDir=modules/a
b.sonar.projectBaseDir=modules/b
c.sonar.projectBaseDir=modules/c
sonar.sources=src
sonar.tests=test
sonar.java.binaries=../**/classes/production,../**/classes/test
sonar.java.libraries=../../libraries/repository
sonar.junit.reportsPath=junit/
sonar.java.coveragePlugin=jacoco
sonar.jacoco.reporthPath=coverage/jacoco.exec
sonar.language=java
sonar.sourceEncoding=UTF-8

Issue has been fixed by correctly setting sonar.java.test.libraries/binaries attributes as answered in https://stackoverflow.com/a/32197912/343806. They were not not in the runner configuration and after adding raised issues in sonarqube results marked as fixed.

Finishing details on a JUnit 4 dynamic suite

Hi – I wanted to automatically sweep JUnit tests into suites as part of my continuous builds, so I derived a runner from JUnit's Suite which finds all test classes in a package. The runner works just fine, but the results display is less than expected.
I have one class in my testing support package with a #RunWith annotation for my runner. The runner works by reading a property to get the package under test. Set the property and tell JUnit to run the annotated class, and all tests in that package are executed. The name of the suite is reported as the name of the class which has the #RunWith annotation, in both Ant and IntelliJ. My runner has an override for ParentRunner.getName() which returns the name of the package under test. I verified that the string gets into the runner's Description object. What am I missing?
Environment:
JUnit: 4.5
Ant: 1.7.0
IntelliJ IDEA: 8.1
Thanks for whatever direction you can provide.

This is because ANT and IntelliJ use their own runners, so they are building the name based on the test, and not getting the name from your runner. In other words, the runner is delegated to for the purpose of running the test, but not for the purpose of describing it.

I had a similar problem just a few weeks ago and created an open source project because of it.
You may include it via maven
<dependency>
<groupId>com.github.cschoell</groupId>
<artifactId>junit-dynamicsuite</artifactId>
<version>0.2.0</version>
<scope>test</scope>
</dependency>
or download it from the github page, where you will find its documentation as well.
https://github.com/cschoell/Junit-DynamicSuite
There is a Junit runner included which allows to scan either a directory or the classpath for unit tests and filter them by implementing a simple interface.