This message was deleted.

• Observation 1 is the consequence of the Jacoco plugin configuring all

Test

tasks of the project for producing coverage data. • Observation 2 is the consequence of the Jacoco plugin only configuring a report task for the default

test

task. So your report configuration on the extension only applies to that report. • I do not know about observation 3 … @Tom Tresansky Could you take a look at the above?

Also regarding Observation 1, keep in mind that the

.exec

file is the input for the

JacocoReport

task, it is an output of the

Test

task that is configured with the JaCoCo agent to produce that file. Regarding Observation 3, yes, the directory exists, but the message says it tries to read it as file which results in an access denied exception. You call the

executionData

method with a

TaskProvider

but the task is not capable of processing that properly. It only accepts

TaskCollection

,

Task

, and

Object

. So in your case the

Object

variant is used which is resolved as if you give it to

Project.files

and thus it's defined outputs are used, which is the test results directory, not the Jacoco data file. As the

TaskCollection

variant would anyway eagerly resolve all tasks and thus prevent task configuration avoidance, you can also directly use eager API and use the

Task

variant. So for example

executionData tasks.integrationTest

should work fine, as the JaCoCo plugin is simply not yet adapted to lazy APIs properly.

Thanks for the quick repliies! Yeah, I'd always thought build/jacoco/*.exec was generated by the jacoco plugin. @Vampire passing the

Task

rather than

TaskProvider

has fixed the issue.

Incredibly clear explanation!

Thanks, @Vampire, for the great explanation! That linked issue is one we should consider as past of continuing work on the Provider APIs, which should become more of a focus for the team soon. @Tom Gregory What the reason is for aggregating execution data across multiple test suites with different `TestSuiteType`s? During development, we were wondering if there would be a need to add an easy way to configure a single report to aggregate either 1) all test suites of any type within a single project or 2) all test suites of any type across all project dependencies present in the

jacocoAggregation

configuration. The initial version of the aggregation feature did not offer this, but we are currently discussing how to expand and improve Test Suites and related features.

I usually prefer to have separate coverage for unit tests and integ tests, as I strive to have full coverage with unit tests and then with integ tests separately around 70 - 80 % in projects where I care about tests. But I also know the position that it is sufficient if any test type tests a code part. For that a combined report over all test types is helpful.

@Tom Tresansky I am sending coverage data to Sonaqube via

sonaqube

plugin. In the SonaQube UI there is a single code coverage statistic. Since I have a single-module Gradle project with unit + integration tests, this is why I wanted to combine the execution data into a single XML report to send to SonaQube. Let me know if there are any other approaches.

You can also give it multiple paths to multiple files

@Vampire do you mean setting

sonar.jacoco.reportPaths

?

yes