Can clover be used for getting code coverage for API integration tests written in TestNg

I have a spring boot application running in one JVM and I am running my integration tests in other JVM on same machine. I have confgured maven-clover2-plugin:4.0.4 to generate distrubted coverage.  I see that although during execution of API integration tests code in Controller and Service layer is executed, but in the coverage stats only the controller source is shown as covered and coverage is zero for Service layer.

here is my package structure -

Source Code package structure -

com.xyz.controller.MyController.java

com.xyz.service.MyService.java

Test Code package structure -

com.xyz.controller.MyIntegrationTest.java

 

 

1 answer

Hi Rohan,

Are controller and service classes located in different Maven modules? 

Are tests kept in the same module(s) as controller and service clasess?

Did the the application server shut down after tests?

 

Lack of code coverage for some of classes may be caused by different factors:

1) Service classes were not instrumented

 - check if you have any inclusion/exclusion patterns in maven-clover2-plugin configuration in pom.xml

 - check if you ran 'mvn clean' before calling clover2:setup (otherwise Maven could have found class files compiled previously and not compile the instrumented sources)

 - check if you see instrumented classes in /target/classes folder - you can recognize them by "<base name>$__CLR<hash>.class" name pattern

 

2) Wrong EAR/WAR content or wrong EAR/WAR deployed

 - depending on how EAR/WAR is assembled, it may happen that non-instrumented classes are packed (e.g. using a cached JAR file instead of the instrumented classes) 

 - ensure that instrumented classes are present inside the WAR/EAR file you deploy for tests

 

3) Database not found at runtime

  - it may happen if you have several Maven modules and you copied only one clover.db file to your application server instead of all clover.db files

 - this usually does not happen if you build & test on the same machine, unless you launch an application from a different working directory than build workspace  - as Clover uses relative paths in initstring

 - check for any Clover-related errors in application log, such as

CLOVER: Unable to load the coverage database at <path>
CLOVER: No coverage data will be gathered.

 

4) Coverage file were not written to disk at the time when report was created

 - by default Clover uses "direct" flush policy, which means that coverage recording files are written at JVM shutdown hook

 - therefore in case you killed an application server (kill -9) or when you did not close the application server (i.e. it runs also after tests are finished) coverage files could have not been written to disk

 - ensure that application sever is stopped or change flush policy to "interval" or "threaded"

 

 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Monday in Jira Ops

Jira Ops Early Access Program Update #1: Announcing our next feature and a new integration

Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...

486 views 0 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you