Code coverage not shown For Spring Boot Microservice calls.

74 views
Skip to first unread message

Balesh koijam

unread,
Dec 17, 2018, 4:55:27 PM12/17/18
to JaCoCo and EclEmma Users
Hello Jacoco Experts,

i have a spring boot - micro service application for which i have written some BDD tests. 

As a further research from my previous POC, i did the following steps to generate the jacoco report.

1. Added the below java agent in the vM options of the run/Debug configurations screen of my TestRunner class. refer the screen shot below:

-javaagent:C:\\Users\\U645789\\IdeaProjects\\jaragents\\org.jacoco.agent-0.8.2-runtime.jar=destfile=C:\\Users\\U645789\\IdeaProjects\\jaragents\\jacocoReward.exec,append=true


s1.JPG


2. i started my spring boot application (micro service) using the boot run option.
3. Executed my BDD tests successfully and found the exec file has generated successfully.
4. Used the "show code coverage data" option of intellji to see the code coverage details and it shows all 0% for all sections. screen shot given below:

s2.JPG



Tried with a simple java class (in the same project) and see if the code coverage was reported correctly. i could see that for the normal simple java class where the actual function if executed directly from my test files, the code coverage details are showing up correctly.

I am having a feeling that code coverage for my actual micro services are not reported due to the way the classes and methods are invoked when the test are executed.

i used the RestAssured library to invoke the micro service. a sample code will be something like this.

Response response = given().
contentType(ContentType.JSON).
body(requestBody).
headers(requestHeaders).
when().
post(resourceURI).
then().
extract().
response();



Any suggestions on what could be root cause will be really appreciated.

Thanks 


Evgeny Mandrikov

unread,
Dec 20, 2018, 1:32:28 PM12/20/18
to JaCoCo and EclEmma Users
Hi,

Unless you provide COMPLETE example that can be easily executed by others,
I seriously doubt that you'll get any answer here.


Regards,
Evgeny

Balesh koijam

unread,
Dec 27, 2018, 1:17:38 PM12/27/18
to JaCoCo and EclEmma Users
here is an example where  i am able to replicate the same issue mentioned.


i had included the jacoco.exec file which was generated, you can use this file to see the code coverage report if required,


Thanks

Evgeny Mandrikov

unread,
Dec 27, 2018, 4:13:32 PM12/27/18
to JaCoCo and EclEmma Users


On Thursday, December 27, 2018 at 7:17:38 PM UTC+1, Balesh koijam wrote:
here is an example where  i am able to replicate the same issue mentioned.


$ bash ./gradlew build

> Task :bdd:compileTestJava FAILED
/private/tmp/j/Example-sb-cucumber-jacoco-project/bdd/src/test/java/stepdef/stepdef.java:8: error: package hello does not exist
import hello.Data;
            ^
1 error

FAILURE: Build failed with an exception.

 
i had included the jacoco.exec file which was generated, you can use this file to see the code coverage report if required,
 
exec files are not portable, because they depend on class files and different versions of compilers produce different class files - https://www.jacoco.org/jacoco/trunk/doc/classids.html
In other words: exec file produced on one machine for one version of class files, will be unusable on the other machine where class files are different.

However according to inspection of exec file content by JaCoCo Command Line Interface ( https://www.jacoco.org/jacoco/trunk/doc/cli.html ):

$ java -jar .jacoco-0.8.2/lib/jacococli.jar execinfo jacoco.exec | grep "hello" | wc -l
0

Your exec file doesn't not contain any information about classes in package "hello".


At VM termination execution data is written to the file specified in the destfile attribute.

Execution data is written during execution of JVM Shutdown hook ( see http://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread) )
Whose execution not guaranteed if JVM was not gracefully terminated.


Which I assume is a hard kill by IDE and not at all a graceful termination.

To quickly confirm this - use different exec files for different JVMs and you'll observe that one used for "boot run" will be empty.

Moreover agent used for JVM that executes your CucumberRunner will never record execution of classes in package "hello", because they are executed by another JVM.

Balesh koijam

unread,
Jan 2, 2019, 10:06:06 AM1/2/19
to JaCoCo and EclEmma Users
Yeah that make sense.
my test was on local machines. let me have a look in the actual dev server where I came to know from one of my engineer that Cucumber test and the service (micro service app) are in the same JVM.
Thanks for your inputs and the suggestions.
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages