Hi,
indeed, interesting observation with the 4 covered branches. I can
reproduce with the small example below. Actually if you look at the byte
code the probes inserted by JaCoCo will create enough information that
both paths for the conditions a and b have been taken. But for the body
itself the implicit exception will prevent it from getting marked as
covered.
Regards,
-marc
import org.junit.Test;
public class Branches4 {
void target(boolean a, boolean b) {
if (a || b) {
exception();
}
}
private void exception() {
throw new IllegalStateException();
}
@Test
public void test1() {
target(false, false);
}
@Test(expected=IllegalStateException.class)
public void test2() {
target(true, false);
}
@Test(expected=IllegalStateException.class)
public void test3() {
target(false, true);
}
}
On 29.04.15 22:29, Timo wrote:
Thanks again for the explanation and the link!
I see the problem now, but I still don't understand how JaCoCo can
tell that all four branches of the if statement are covered but
assumes that the body was not covered. I guess that is because I have
almost no understanding of how Java source code is compiled to
bytecode and know even less how exactly JaCoCo inserts probes.
Something to figure out on a cold and rainy evening ;-)
Any ideas how I could restructure my code to see less "false
positives" with JaCoCo?
2015-04-29 21:50 GMT+02:00 Marc R. Hoffmann
<[email protected] <mailto:[email protected]>>:
It is a limitation by design: JaCoCo adds probes very sparingly to
limit the runtime overhead. That's why it is the fastest coverage
tool which scales also for *very* large code bases.
In case you're interested here are more detailed information about
the probe insertion strategies of JaCoCo:
http://www.eclemma.org/jacoco/trunk/doc/flow.html
Regards,
-marc
On 29.04.15 21:42, [email protected]
<mailto:[email protected]> wrote:
Am Mittwoch, 29. April 2015 20:24:18 UTC+2 schrieb Marc R.
Hoffmann:
Hi,
I don't know, what the SystemExitHandler in line 42
actually does,
but if it does a System.exit() and the method never
returns the
whole block is not marked as covered. This is a
documented
limitation, see our FAQ:
http://www.eclemma.org/jacoco/trunk/doc/faq.html
Code with exceptions shows no
coverage. Why?
JaCoCo determines code execution with so called
probes.
Probes are inserted into the control flow at
certain
positions. Code is considered as executed when
a subsequent
probe has been executed. In case of exceptions
such a sequence
of instructions is aborted somewhere in the
middle and not
marked as executed.
Regards,
-marc
On 27.04.15 21:21, [email protected]
<mailto:[email protected]> wrote:
Hello everyone,
I have an issue with JaCoCo that I don't understand. It
might be a bug or just me being stupid so I thought I ask
before opening an issue.
I created a project on GitHub [1] and integrated it with
coveralls.io <http://coveralls.io> using the JaCoCo Maven
plugin to generate the coverage report. The issue surfaces
in the run method of the Main class on line 48 [2]: all
branches of the if statement are covered in tests and yet
JaCoCo reports the body of the if statement as uncovered.
It is not an issue with coveralls.io <http://coveralls.io>
because the exact same coverage is shown in the JaCoCo
HTML report if I build the project on my machine. The HTML
report even states on line 48 that "all 4 branches [are]
covered".
Am I doing something wrong?
[1] https://github.com/hzpz/access-export
[2]
https://coveralls.io/builds/2422271/source?filename=src%2Fmain%2Fjava%2Fnet%2Fkockert%2Faccess%2Fexport%2FMain.java#L48
Hi Marc,
thanks for your reply!
I know about this limitation and that is one reason the
SystemExitHandler interface exists ;-) The implementation I
use in tests does not call System.exit() but throws an
exception instead. This way I am able to use JUnit's @Test
annotation with an 'expected' in my tests.
By the way, both Cobertura as well as the coverage runner
integrated in IntelliJ IDEA 14.1 report the coverage that I am
expecting. I am more and more convinced that this is a bug in
JaCoCo. Or is it just another limitation?
Any thoughts?
Timo
--
You received this message because you are subscribed to a topic in
the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/jacoco/gIubNSFGNlU/unsubscribe.
To unsubscribe from this group and all its topics, send an email
to [email protected]
<mailto:jacoco%[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/554135F6.1050200%40mountainminds.com.
For more options, visit https://groups.google.com/d/optout.
--
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]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/CAONNSUYDwcxgVW73pDMhzF4YmnEbea0%2BAGuE6j4mZo%2BRu1fudg%40mail.gmail.com
<https://groups.google.com/d/msgid/jacoco/CAONNSUYDwcxgVW73pDMhzF4YmnEbea0%2BAGuE6j4mZo%2BRu1fudg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/55414854.7010703%40mountainminds.com.
For more options, visit https://groups.google.com/d/optout.
