evosuite code coverage does not match with jacoco coverage

Question

I am using evosuite 1.0.3 version. I am able to generate the test classes successfully and the project_info.xml shows 0.75 as code coverage which is nothing but 75% (0.75*100).

But when I have integrated with Jacoco code coverage tool, I am not seeing 75% as the coverage. It is showing as 13% only. What could be the reason for this?

Below is the output when I have issued mvn evosuite:info.

[INFO] Total number of classes in the project: 12

[INFO] Number of classes in the project that are testable: 12

[INFO] Number of generated test suites: 10

[INFO] Overall coverage: 0.7541666666666665

Shouldn't I see the coverage in jacoco report also as 75% as overall coverage? Please help.

Answer 1

Without Minimal, Complete, and Verifiable example hard to tell exact reason and suggest something precise to solve your problem, however quoting EvoSuite documentation about code coverage:

... the class under test (CUT) has to be instrumented, i.e. its bytecode needs to be modified.

Unfortunately, those bytecode modifications might conflict with the bytecode instrumentations done by tools used to measure code coverage (e.g., JaCoCo, EclEmma, Cobertura, Clover and JMockit). So it could well end up that you get 0% code coverage ...

In the meantime, if you get 0% coverage, you can try ...

Also there are two modes in JaCoCo - so called "on-the-fly" instrumentation with Java agent that is recommended by default, and so called "offline" instrumentation without agent. In absence of example unclear how JaCoCo is launched in your case, however in addition to the workaround on EvoSuite documentation page maybe JaCoCo "offline" instrumentation might help - quoting JaCoCo documentation about offline instrumentation:

One of the main benefits of JaCoCo is the Java agent, which instruments classes on-the-fly. This simplifies code coverage analysis a lot as no pre-instrumentation and classpath tweaking is required. However, there can be situations where on-the-fly instrumentation is not suitable, for example:

• ...
• Conflicts with other agents that do dynamic classfile transformation.

For such scenarios class files can be pre-instrumented with JaCoCo ...