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
Unfortunately, IJ API requires us to return instances of
PsiClass/PsiMethod in order to proceed with run configuration creation.
In fact, those instances will be queried only by trivial requests, like
containingFile or name. Therefore, full-blown LightClasses are not
needed and even harmful, because for some declarations we can not build
proper light classes (like for expect declarations, for example)
Previously it mostly worked because most of declarations in common
indeed have corresponding Light-instances (because common source-set can
be seen from Java through JVM-part of a project).
^KT-34503 Fixed
This allows us to check two things:
- presence of line markers (haven't been checked by old
GradleTestRunConfigurationTests, though could've been checked by
LineMarkerTests)
- some properties of run configurations which will be created from those
line markers
Old GradleTestRunConfigurationTest have been renamed to
GradleTestRunConfigurationCustomTest and slightly modified to be able
to re-use the same testdata if necessary.
Previously, GradleDaemonAnalyzer reused common IJ infrastructure for
highlighting tests (see DaemonAnalyzerTеstCase, ExpectedHighlightingData
and such).
Unfortunately, this infrastructure had several flaws,
mainly around checking expected highlighting against actual one:
- overlapping line markers lead to crash (fixed in 193+)
- no way to sanitize descriptions of line markers (important for cases
where description returns HTML-formatted text, which makes testdata
completely unreadable and also drives parser insane)
- thrown FileNotFoundException doesn't have a physical file with
expected testdata attached, which makes browsing diff a little less
convenient (no way to apply changes to expected file)
- no easy way to plug-in with additional after-highlighting checks
This commit fixes it by overriding doCheckResult and providing custom
checking of highlighting/line markers, based on TagsTestDataUtil.
Because we don't rely on IJ-checking anymore, we also remove weird hoops
with removing/adding testdata markup in checkFiles.
Also this commit adds strings sanitization in TagsTestDataUtil, removing HTML-tags
and line breaks, so that description of tag is always one-liner with
plain text.
Nikolay Krasko