Include integration test in Jacoco coverage reports #31
Conversation
rstata
force-pushed
the
covagg
branch
2 times, most recently
from
e80675f to
862d62c
Compare
| * with the unit tests from the base project to generate a full coverage report | ||
| */ | ||
|
|
||
| import org.gradle.api.attributes.* |
There was a problem hiding this comment.
I'm sure you are aware of this, but this seems like a lot of gradle specific, quasi-internal details, and therefore might be fragile.
This seems like a common type of thing to do. Perhaps we can find an example on the internet of a codegen tool that has Jacoco integration tests that does this in a simpler way.
There was a problem hiding this comment.
i'm not sure i see that we're using quasi-internal details here. that said, i did take a pretty serious look at an alternative. in particular, the jacoco-report-aggregation plugin. i think there are things that i'm doing in the tasks created by registerCoverageTask that might be built into jacoco report aggregation. that said, any complexity here is due to the fact that the base project and the integration-test project are in different builds in our composite build. this means we should be using configurations to connect these tasks. in attempting a quick prototype that used jacoco report aggregation, i was quickly recreating pretty much everything in this PR.
settings.gradle.kts
Outdated
|
|
||
| includeBuild(".") | ||
| includeBuild("included-builds/core") | ||
| includeBuild(".") // TODO - is this needed? |
There was a problem hiding this comment.
Yes, it's necessary. It allows the viaduct-bom project to be resolved by other included builds (like the demo apps).
| attribute(Category.CATEGORY_ATTRIBUTE, objects.named(Category.VERIFICATION)) | ||
| attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage.JAVA_RUNTIME)) | ||
| attribute(Bundling.BUNDLING_ATTRIBUTE, objects.named(Bundling.EXTERNAL)) | ||
| attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named("jacoco-exec")) |
There was a problem hiding this comment.
I don't think the other attributes are necessary, this one is a critical one. We should try removing the other ones (here and also in other similar attribute sets).
|
|
||
| // The following is not just a cross-project task-dependency, it's a cross-build one. | ||
| // However, configurations alone were not enough to force execution of the :sourcesJar task. | ||
| // TODO - fix this (maybe a proper task subclass would fix this). |
There was a problem hiding this comment.
Theoretically this should be as simple as:
tasks.register<Copy>("unpackRuntimeClasspathJars") {
val outputDir = layout.buildDirectory.dir("unpacked-libs")
from({
configurations.runtimeClasspath.get().map { zipTree(it) }
})
into(outputDir)
}If it's not, then maybe the problem is not here, but in the projects that generate the sources.
I would say, if it works, leave it and we can come back to it later, investigate, improve.
Description
See Issue #30. Copying the description: "Many tests of the Tenant API implementation are performed by integration tests that depend on code generation. The source for these tests is found in
integrationTestsource sets, but are built an run by the integration-test Gradle projects (e.g.,tenant/runtime-integration-tests). The off-the-shelf configuration of Jacaco does not include those tests in its coverage reports, so those reports are not as useful as they could be. The goal of this issue is to configure Jacoco so that it includes integration tests as testing code from their respective main source sets."Motivation and Context
How has this been tested?
Manual creation and inspection of coverage reports.
Types of changes
Checklist: