Consider a configuration option that turns off the special handling of 'test'

[jjohannes]

Is your feature request related to a problem? Please describe.

In standard JVM projects, additional source sets like testFixtures or someCustomTestSuite are all considered independent variants of a component (see #854). This means that they need to declare all their dependencies. And are not expected to "inherit" any dependencies from main.

The test source set behaves different though. Here the dependencies from main are inherited and if you redeclare a dependencies in test – e.g. implementation("commons-io:commons-io") and testImplementation("commons-io:commons-io") – the recommendation is to remove the testImplementation(...) dependency.

This corresponds to the traditional setup in Gradle, where the Configurations of the test source set inherit from the Configurations of the main source set. Which in turn is a behavior that more or less corresponds to the Scopes in Maven.

Conceptually, I think both perspective can makes sense:

1. If test contains unit tests that deeply reach into the production code (e.g. test protected methods), the tests can be seen as an extension of the main code rather than an independent variant of the component.
2. If test contains functional tests that test the complete component through public interfaces, the tests can be seen as an independent variant of the component.

Describe the solution you'd like

If we want support defining "non-unit" tests in test, it would be great to have a configuration option for this like:

dependencyAnalysis.issues {
  testAsStandardSourceSet.set(true)
}

Describe alternatives you've considered

This is a nice to have I think. You can still get the desired setup by putting non-unit tests into other source sets (e.g. functionalTest or integrationTest) for which you automatically get the "independent variant" (2) behavior.

Additional context

I filed this issue to document and explain this behavior. And to have something to link to in projects that have to make setup decisions because of this. This issue can be closed if the described alternative is considered to be sufficient.