For most of those the behaviour isn't set in stone, though at the moment
of making that commit we're more or less sure that it's reasonable.
Behaviour in some cases might be more strictly enforces (as much as you
can enforce something in esoteric cases with misconfigured project
sturcture). Those are marked with comments with '!'.
Note the behaviour in 'precisePlatformsWithUnrelatedModuleHmpp': it is
incorrect, as set of platforms still contains unrelated platforms.
This is because in the current solution, some source-sets
(commonMain/commonTest) always receive COMMON platform and then it gets
coerced to set of targets actually seen in the project.This helps if
projects uses as much targets as current module (like in
precisePlatformsHmpp), but fails if it uses more targets than the
current module (like in precisePlatformsWithUnrelatedModuleHmppp)
The upcoming commits will fix that issue
Basically, the former uses an old quickly-scrapped infrastructure,
which were not applicable for HMPP, so the latter tests were written.
So, both check for one and the same thing (highlighting in MPP projects),
but MultiplatformAnalysisTest is more modern,
and has a lot of inconvenient stuff in MultiplatformHighlighting fixed
^KT-43116 Fixed
When 6.5.1 Gradle version was added, more tests have began to fail
because of legacy gradle-plugin versions (1.1., 1.2.) which are not
compatible with the new version of Gradle. This commit updates the used
version of the Gradle plugin to the latest stable (1.3.72) and makes it
configurable from tests.
In the master version of plugin dependencies on stdlibs are enabled
by default. It is not expected for some tests.
Flag kotlin.stdlib.default.dependency=false fixed it.
Defined 4.0 and 1.3.0 as default versions of Gradle and plugin for PluginTargetVersions
Use `{{kotlin_plugin_repositories}}` template in testData of ImportTests
Update "mute" databases for new tests
Add `kotlin.stdlib.default.dependency=false` to some testData
Short description.
It's a corner-case with old MPP plugins and AS, so we
don't care too much that it works incorrectly, but we'd like to avoid
muting it in order to keep track of this "known issue"
Long description.
In IDEA, KotlinJvmTestMethodGradleConfigurationProducer successfully
returns run configuration; in AS, it fails to do so.
This is becasuse it doesn't override 'forceGradleRunner', which means
that in 'setupConfigurationFromContext' we'll delegate to super-call,
which will pull 'GradleProjectSettings.getTestRunner()'.
In IDEA, it will return GRADLE, but in AS it will return PLATFORM,
because AS uses special instance of GradleProjectSettings which forces
runner to PLATFORM.
Note that KotlinMultiplatformJvmTestMethodGradleConfigurationProducer
does override 'forceGradleRunner' to true, that's why other tests work
successfully. However, this test uses old 1.2.X-MPP plugins, therefore
all new KotlinMultiplatform*ConfigurationProducers won't work here.\
Otherwise, path will be set to the root project. Given that we provide
task names in relative form rather than absolute, that will lead to
launching this task in all subprojects (e.g. task 'jvmTest'). This might
be a huge issue, because when we create run configuration for specific
test method/class, we pass test filter as well. This test filter will
execute in all projects with matched test tasks, so if some other
subproject has similarly-named test task, but doesn't have a suitable
tests for that filter, the whole build will fail.
Note that the ideal fix would involve using fully-qualified task names:
the current approach might lead to isses in advanced scenarious (e.g.
when user selects several test files from different modules -- then, we
won't be able to find one exact project path for the whole test run)
^KT-35038 Fixed
Dmitry Savvinov