jansauer / gradle-print-coverage-plugin

Scraps jacoco test reports and prints the code coverage to the console
16 stars 9 forks source link

Plugin should not inject itself into the Gradle task dependency tree #21

Open TheFriendlyCoder opened 1 year ago

TheFriendlyCoder commented 1 year ago

I was debugging some strange test behavior in a fairly large Java / Gradle project I've been working on, which I managed to isolate to this plugin.

Problem The project in question has several different test suites (ie: leveraging the gradle-testsets-plugin. Among the test suites are some unit tests (quick to run) as well as integration tests (slow to run). In order to ensure that we get updated Jacoco coverage reports from each build, and that each Jacoco report has the necessary dependencies to run, I have the following Gradle config:

jacocoTestReport { dependsOn test } jacocoIntegrationTestReport { dependsOn integrationTest } test { finalizedBy 'jacocoTestReport' } integrationTest { finalizedBy 'jacocoIntegrationTestReport' }

This configuration works fine, that is until one or more of the test configurations adds the "printCoverage" plugin to the task dependency tree. Consider the following example:

test { finalizedBy 'jacocoTestReport' finalizedBy 'printCoverage' }

When combined with the previous task configuration we end up with the unfortunate result of every time we run the unit test suite (ie: ./gradle test) we get EVERY SINGLE TEST SUITE getting executed instead of just the one test suite that we've chosen.

Root cause After doing a considerable amount of investigation I discovered this line hidden in the plugin implementation which is overriding the default task dependency tree and making the printCoverage plugin depend on EVERY SINGLE JACOCO TASK in the build. So as a result the dependency chain resolves into something like this:

test -> printCoverage -> jacocoIntegrationTestReport -> integrationTest

Expand this example at scale, into a large project with a half-dozen independent test suites, and you can see how this will cause a problem.

Proposed solution This plugin should not be injecting itself into the dependency tree like this. If someone wishes to have coverage displayed for specific test suites, or all test suites, they should have the flexibility to do so on a case-by-case basis.

TheFriendlyCoder commented 1 year ago

NOTE: This also breaks the Gradle plugin recommended best practices:

https://docs.gradle.org/current/userguide/authoring_maintainable_build_scripts.html#sec:avoiding_inter_project_configuration