Test Classpath containing conflicting classes with gradle

[appleseedexm]

Background:

We migrated a multi-project Spring project to gradle. With maven everything worked. With gradle we noticed that vscode-java-test would fail on Spring integration tests due to conflicting beans, but the tests would run when executed with ./gradlew test.
I expected the classpath inconsistencies to be the reason for this, that vscode-java-test would load classes from a test folder even though we only have a dependency to the testFixtures of a project. I was able to confirm that with deleting the conflicting classes from the test folders.

I reproduced this outside of Spring in a simple gradle starter project. If this project is tested with ./gradlew test, the tests execute successfully, with vscode-java-test they will fail (app/src/test/java/org/example/app/MessageUtilsTest.java). The reason is that it will inject the ConflictingClass.java from test instead of testFixtures, or probably both, but with test being prioritised.

Reproduction steps:

1. Checkout gradle starter project.
2. run ./gradle test - should be successful
3. run app/src/test/java/org/example/app/MessageUtilsTest.java with vscode-java-test

Expected behaviour:

Test run through successfully

Actual Behaviour:

Tests fail

Environment

• Extension: v0.41.1
• VSCode: 1.90.0
• OS: Arch Linux 6.9.6-arch1-1
• Java: openjdk 17.0.11 2024-04-16 LTS
• Gradle: `8.81

Same behaviour also happens in neovim with vscode-java-test 0.40.1

Obviously fixing this would be amazing, but maybe there's a possible workaround with buildship to fix the classpath? This particular case is about test vs testFixtures, but I was so far not able to rule out this behaviour between main and test.

Edit:
I played around with it more and noticed that in vscode buildship occasionally reports The type ConflictingClass is already defined. We did not encounter this with classes in our Spring project.

[jdneo]

Thank you. It's just about the right time to ask about this.

I'm recently implementing test delegation to Gradle, which will solve your problem. The code is closed to be ready and I've verified that using the new way to run test, the issue is gone.

Stay tune: microsoft/build-server-for-gradle#119

[jdneo]

dup: #1045 (comment)

[jdneo]

The Gradle Test Delegation (both run and debug) has supported now.

To use this feature, you need to install the latest Test Runner for Java and Gradle for Java extension.

To delegate the tests to Gradle, you can set the default testing profile in Testing explorer:

If you do not want to change the default testing profile, you can trigger an one-time execution via: