Hi,
we discussed this limitation many times before. Currently JaCoCo is
designed to add the smallest possible overhead to the application under
test as JaCoCo is mainly used for large scale projects.
I like the idea of adding additional probes before every INVOKE*
instruction as this is the most likely place for implicit instructions
(beside NPE, IOOB, CCE, etc.). It would be interesting to see how this
increases
1) the total number of probes
2) the execution time
for a reasonable sized test set like e.g. Apache commons collections.
BTW, I don't think this feature could be configurable: The way to
determine probes has to be absolutely deterministic at runtime and
analysis time. So it has to be ensured that the config setting must be
the same. Or the setting is written to the exec file, which makes
merging impossible of exec files with different settings.
Cheers,
-marc
On 03.11.14 18:15, [email protected] wrote:
Dear all,
JaCoCo does not detect that certain instructions are run (covered) if these
lead to an implicit exception. In the following example, if c() throws an
exception, the result indicate no coverage for b().
public void foo() {
a();
try {
b();
c();
} catch (Throwable t) {}
}
In the following example, no coverage at all is reported, assuming c() again
throws an exception.
public void bar() {
a();
b();
c();
}
Note that the last example is quite common when writing JUnit 4 tests using the
"expected" keyword, as in the following example.
@Test(expected=SomeException.class)
public void testBar() {
...
}
I experimented with adding more probes inserted in front of opcodes that may
thrown an (implicit) exception. With such probes more precise coverage results
are obtained, at the cost of having more probes. This means a slower execution
(analysis) speed, and bigger instrumented class files.
In my _preliminary_ experiments I see about 1-2% of increased coverage, if
coverage of the Test classes is included in the report. This comes at the cost
of about 1% more runtime when compared to the current release of JaCoCo.
I am now interested in your opinions on this. Do you think having a more
precise analysis as described is worthwhile? Should the feature be in JaCoCo,
or not? Should it be configurable, possibly disabled by default?
On a more technical note, it is possible to only add probes for some of the
opcodes which may thrown an exception. For example, one could add probes for
INVOKE opcodes (which would help with the JUnit tests, based on my experience),
and not add probes for PUTFIELD and array opcodes.
Best regards,
Carsten
--
You received this message because you are subscribed to the Google Groups "JaCoCo
and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
