Jacoco report when integration tests are ran from separate maven module

[pa...@kuruma.co.uk]

I used a working example I wrote previously and the only difference is that I moved the integration tests to another module on their own.

When I run the tests the failsafe tests run ok and a jacoco exec file is created, I dont know if it is right or not but it has class names that are in my war file.

The report doesnt seem to generate, if I try to report in the verify phase then I get this message:

Skipping JaCoCo execution due to missing classes directory:

If I run the report goal in the pre-integration-test phase then a report of sorts is created but there is no code coverage in there, and just the index.html and sessions files are created.

I am using jacoco 0.7.6.201602180812

Is there something extra that needs to be done to get a coverage report if the classes are built in another module of the project?

[pa...@kuruma.co.uk]

Should have said "post-integration-test" phase, sorry.

[Marc R. Hoffmann]

Hi Paul,

with the current JaCoCo release reports are only supported within one
module: Exec file from test execution and class files have to be in the
same module. Creating reports accross module boundaries is supported
with the new "report-aggregate" goal of the next JaCoCo release.

Regards,
-marc

[pa...@kuruma.co.uk]

Ok thanks I got this working actually I don't completely understand why the report goal requires the classes, could you tell me?

http://stackoverflow.com/questions/37410322/code-coverage-in-maven-build-skipping-jacoco-execution-due-to-missing-classes

I posted the above asking for help but managed to get something working by copying the classes which are exploded into the cargo directory when tomcat deploys my war during the build of my integration test module.

It seems a bit 'hacky' but it seems to pick up coverage driven from my selenium tests against my front end web app.

[Marc R. Hoffmann]

Hi,

from JaCoCo documenation:

JaCoCo tracks execution with so called probes. Probes are additional byte code instructions inserted in the original class file which will note when they are executed and report this to the JaCoCo runtime. This process is called instrumentation. To keep the runtime overhead minimal, only a few probes are inserted at "strategic" places. These probe positions are determined by analyzing the control flow of all methods of a class. As a result every instrumented class produces a list of n boolean flags indicating whether the probe has been executed or not. A JaCoCo *.exec file simply stores a boolean array per class id.

At analysis time, for example for report generation, the *.exec file is used to get information about probe execution status. But as probes are stored in a plain boolean array there is no information like corresponding methods or lines. To retrieve this information we need the original class files and perform the exact same control flow analysis than at instrumentation time. Because this is a deterministic process we get the same probe positions. With this information we can now interfere the execution status of every single instruction and branch of a method. Using the debug information embedded in the class files we can also calculate line coverage.

Regards,
-marc

[pa...@kuruma.co.uk]

Hi Marc,

Thanks, I think I understand what is happening now although I thought I saw a diagram that indicated it did it on the fly by injecting a jar reference into the running jvm (in this case tomcat running in cargo) and doing something when classes were loaded?

Just so I can properly get my head around this, you are saying that the actual physical class file files that were exploded from my war file have actually been changed and have additional instructions in them?

And the reason I can get the coverage report working is because I am then copying these files (after the agent set up) into the target/classes directory?

So at what point is jacoco physically changing the unpacked class files?

At the phase that I run the agent set up I havent even unpacked the war file yet so it doesnt even know about the classes until I unpack the war and then start tomcat passing in the jvm argument for the jacoco jar to cargo?

I am really confused now! Are the classes permenently changed after jacoco does its analysis?

Thanks,

Paul

[Marc R. Hoffmann]

Hi,

what happens "on the fly" is instrumentation at runtime. You were asking
about report generation, right? Class files are required here but are
not modified.

Unless you use offline instrumentation (which is not recommended) class
files are never changed by JaCoCo.

Regards,
-marc

[pa...@kuruma.co.uk]

Hi Marc,

I am asking about report generation yes, but wanted to understand why the exact same classes needed to be passed to the report generation and I thought it was because you were saying they have been changed and additional instructions have been inserted into them?

Sorry if I am being stupid but this:

"Probes are additional byte code instructions inserted in the original class file which will note when they are executed and report this to the JaCoCo runtime."

Implies to me that the actual file has been changed by jacoco instrumentation?

[Marc R. Hoffmann]

Hi,

no, instrumentation happens in-memory only while class loading. This is
the nice thing about the agent.

Regards,
-marc

[pa...@kuruma.co.uk]

Ok thanks for the help Marc, I finally understand what is happening and why I am able to get coverage working in a separate module by copying my classes and its not even 9am yet!