NeoTech-Software/Android-Root-Coverage-Plugin

Can you add configuration for ignore modules in `rootCoverage` block

trietbui85 opened this issue · 3 comments

trietbui85 commented

I understand we can disable coverage for any module with android.debug.testCoverageEnabled true. However, it seems manually if there are too many modules.

Could you consider adding new field to rootCoverage block:

rootCoverage {
  ignoredModules = [ "moduleA", "moduleB"]
}

(the ignoredModules will prevent coverage script to execute in these modules, even it has testCoverageEnabled true).

Rolf-Smit commented

This is something I have been thinking about for a while now, I also want to get rid of reusing the testCoverageEnabled property. This will probably be included in a next release.

  • 👍2
0neel commented

@Rolf-Smit

I also want to get rid of reusing the testCoverageEnabled property

does it mean the property is used only as a configuration flag and brings no other benefits?

Rolf-Smit commented

Update:

I have been thinking about this and trying some different things and decided that using this property is right now still the best way forward:

In Android Gradle Plugin 7.3 Google deprecated the testCoverageEnabled property in favor of 2 other properties enableUnitTestCoverage and enableAndroidTestCoverage, release 1.6 of this plugin will support these 2 new properties as well as the deprecated property.

You may ask why? The reason is currently simple, these properties are required. Without them the Android Gradle Plugin itself will not instrument code with JaCoCo, which is required for code coverage in the first place. Therefore these must be enabled. But why can't this plugin enable them automatically? Well that has to do with the fact that in order for this plugin to do that, there should also be a way for people to configure for which modules that should happen, and because this all happens at configuration time, by the time the plugin knows for which modules to enable the property the Android Gradle Plugin no longer allows changing it from false to true (or the reverse).

@0neel these properties are used by this plugin as configuration flags to determinate whether to configure reporting for a certain module. If disabled this plugin will not configure reporting for that module. But these properties are also required regardless, because if you don't enable these, code will not be instrumented by JaCoCo in the first place. So this plugin is essentially only reusing these properties to check if instrumentation is enabled in the first place, and if so configures reports.

  • 👍1