Hi Seamus,
Java has no notion of "package hierarchies". All packages are separates,
even if they share a common name prefix. The same applies for JaCoCo
reports: As you notices coverage figures are for a package are based on
all classes whithin this package only. Classes from other packages are
not considered.
Regards,
-marc
On 01.04.16 18:18, Seamus Reynolds wrote:
Hey folks,
So I've been running Jacoco on a project for a few months now, (via
the Gradle plugin), and have generally been rather happy with it.
However, I recently did a big refactor of a high-level package in my
project, and I noticed that Jacoco no longer seems to be
grouping/structuring package hierarchies correctly. Or, to put it
another way, a package's code coverage statistics seem to be based
purely on the classes directly under it, and not the classes that are
an additional package level down.
Example:
* com.example.api - Code Coverage 80%
o Class1 - Code Coverage 100%
o Class2 - Code Coverage 60%
o com.example.api.server - Code Coverage 40%
+ ServerClass1 - Code Coverage 100%
+ ServerClass2 - Code Coverage 0%
+ ServerClass3 - Code Coverage 20%
So, the code coverage for *'com.example.api'* is listing as 80%, which
seems to only be based on the classes directly in 'com.example.api'.
It's not considering the classes in the subpackage
*'com.example.api.server'* when calculating the total coverage for the
*'com.example.api'* package. This appears to be happening for all of
my packages, regardless of their place in the overall package structure.
From what I can tell, this isn't related to the report generation, but
rather based on the resulting exec files themselves. (I'm basing that
on seeing the same results in both a report from Jenkin's based on the
exec data, and the html report generated by the Gradle
JacocoTestReport task).
The html report winds up looking something like this
<https://lh3.googleusercontent.com/-SIeJ1RI4EAs/Vv6eMUAs-1I/AAAAAAAARXM/E0fdEAoyxEscwUh_XyX1LTUdlT6pH5RaA/s1600/JacocoReport.png>
Rather than with packages grouped under each other, like this:
<https://lh3.googleusercontent.com/-9-LJDgZ_BRY/Vv6ehXt_AXI/AAAAAAAARXQ/xr3zWxwnRfoLBWzMuNvYhOTOicT0c9VMw/s1600/JacocoExampleReport.png>
A few hours of googling around, looking at the Jacoco site, searching
the discussions here and on GitHub haven't seemed to return a
reference to this particular problem. Does anyone have any thoughts or
suggestions?
Here's my configuration for Jacoco in Gradle, which is what's
orchestrating the execution of a Jacoco ant task in the background,
generating the .exec file.
jacoco {
toolVersion ="0.7.6.201602180812"
}
jacocoTestReport{
//Test targeting configured here
classDirectories = files(sourceSets.main.allJava.srcDirs)
reports {
csv.enabledfalse
xml.destination"${buildDir}/reports/jacoco/xml"
html.destination"${buildDir}/reports/jacoco/html"
}
executionData = files('build/jacoco/test.exec')
doLast {
//Prints a clickable link in the terminal, if your terminal
emulator supports that
println"*** JaCoCo Report:
file://${buildDir}/reports/jacoco/html/index.html ***"
}
}
--
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/ac248218-a25a-4a94-b5b8-9d4c710486a8%40googlegroups.com
<https://groups.google.com/d/msgid/jacoco/ac248218-a25a-4a94-b5b8-9d4c710486a8%40googlegroups.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/5701FCBA.8040909%40mountainminds.com.
For more options, visit https://groups.google.com/d/optout.
