https://kotlinlang.org logo
Join Slack
Powered by
Is it IntelliJ or testBalloon plugin that determin...
# testballoon
p
Is it IntelliJ or testBalloon plugin that determines the run-configuration for tests when using the gutter icons? We have a project (
project-a
) that is also composited into another build 
project-b
(using 
includeBuild
). Both the project and the composite build are open in the same IntelliJ (workspace). When running tests from the icon in that project we're seeing the gradle task being determined as 
:project-a:test
but the gradle project for the run configuration being 
project-a
and no tests are found or executed. Correcting the run configuration (either to call 
:test
against 
project-a
or 
:project-a:test
against 
project-b
) works.
o
I'd say these are mostly IntelliJ mechanisms, but if you have a reproducer, you could create an issue with TestBalloon and I'll see whether something can be done in the plugin or I'll forward the case to the IntelliJ folks.
p
Sure I'll see if I can put one together
👍 1
I've put github.com/tKe/testballoon-composite-mre together - it has no README yet but I need to grab dinner. I'll get one in later. Essentially open that repo as an IntelliJ workspace and at least for me, running 
InnerSuite
in the inner-project will fail.
👍 1
o
Worked correctly over here with IJ 2026.1.3. The run configuration looks as expected:
p
o
No.
I added "outer-project" manually for the IDE to recognize it.
Right-clicking on 
outer-project/settings.gradle.kts
and then "Link Gradle Project".
p
Ah, ok - yes that seems to work, when only the outer-project is added/linked directly. If you had instead linked inner-project, and then linked outer-project you should end up seeing the issue. You may need to unlink outer-project first.
(our actual use-case is compositing in the build of another service to substitute its "api" sub-project, but this example is simpler if not of any obvious value)
o
Even in that case it worked for me: Linked "inner-project", which made the IDE auto-unlink "outer-project". Linked "outer-project". Ran 
InnerSuite
from the gutter.
But does it make sense to link "inner-project" if that already appears as part of "outer-project" in the Gradle tool window?
Also tried to start with zero Gradle projects linked. Still seeing no failure.
p
Have you deleted the run configuration (it certainly seems to reuse it if present, even if we've manually fixed it)
o
Yes,
Of course, otherwise reuse will happen.
p
I'm hoping this plays for you. Even just linking outer-project (this is from a fresh load of IntelliJ after clean checkout and removing the .idea folder) and running 
InnerSuite
gets the wrong configuration for me (I've removed the workspaces plugin - this is on 2026.1.4). Sorry for taking up your time, but I appreciate you looking into it :)
Screen Recording 2026-07-17 at 22.00.24.mov
o
No worries! Played for me, I see the problem, I know where this comes from (an IDE property called 
org.jetbrains.kotlin.config.ExternalSystemTestRunTask#getExternalSystemProjectId
). And luckily, while trying to video the same thing, I got a reproduction: Closing the IDE after unlinking everything and cleaning up run configurations made a difference. Seems like something confuses the IDE, but now I can try to track it down.
kodee happy 1
p
At least I'm not (just) going insane then!
o
Kodee beware!
kodee intensifies 1
One step closer: The property is OK, JUnit/kotlin.test run configurations work the same. The difference is that if the "fully qualified" project name is used for "inner-project", the run configuration's "Gradle project" must be "outer-project", but the TestBalloon IDE plugin configures it as "inner-project". The source of that "Gradle project" is also the IDE, but something must be different. I'll find out, but this might take a while (there are tons of functions creating run configurations inside the IDE).
Found a fix. Needs to be checked against other project configurations in order to avoid regressions. Give me a couple of days.
❤️ 1
p
That's awesome, thanks! No rush, we have the workaround of manually correcting the run config.
o
I'll create a tracking issue, but probably not right now. 🥱 Cause was: Two IDE functions seemingly returning the same thing: 
module.externalProjectPath
and 
resolveProjectPath(module)
. The former one is more Kotlin-y (val getter), but seemingly does the wrong thing in exactly this case. The latter one does the right thing, hopefully everywhere.
Thank you for reporting and providing the reproducer! github.com/infix-de/testBalloon/issues/92
p
If it's of any help, I'm happy to test a pre-build of the plugin locally to confirm it fixes the issue in our more complicated build hierarchies 🙂
o
If you'd like I can always publish a pre-build on the marketplace without making it public (so folks don't auto-download it by accident). I'm pretty sure that it fixes the issue. The thorny thing in testing is that it doesn't fail on configurations where it was working correctly before.
4 Views
Open in Slack
PreviousNext
Powered by