You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Gradle and VS Code - Test Explorer panel Issue #1835
We have a project with multiple TEST scopes. int - for unit test, intTest for integration testing, and manualTest for manualTests. In each scope we create tests for the category, however the packages are the same between the scopes. VS Code will not show all the tests from multiple scopes if they are in the same package. I have created a test project to show the example.
Hi mfarich, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.
Suggestions for Multi-Sourced Gradle Tests in VS Code
Workaround: Unique Package Roots
VS Code’s Test Explorer groups tests by package and currently only auto-discovers the default test source set. If you have custom Gradle source sets (intTest, manualTest) that share the same package names, only one set will appear. To work around this:
Refactor each source set to use a different package root (e.g. com.example.unit, com.example.integration).
Or open each test source set as its own folder in a multi-root workspace so they don’t collide.
Custom Test Configuration
You can explicitly tell the Java Test Runner where to find classes for each scope by adding entries to java.test.config in your VS Code settings.json. For example:
The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!
Hi mfarich we’ve released a prerelease version 0.44.2026030602 of test-runner-for-java, which fixes the issue you reported. Please install this version together with the latest prerelease of vscode-gradle and help verify the fix.
you may find the details in the PR, which contains the record about this fix
before
Activity
github-actions commentedon Feb 12, 2026
Hi mfarich, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.
Suggestions for Multi-Sourced Gradle Tests in VS Code
Workaround: Unique Package Roots
VS Code’s Test Explorer groups tests by package and currently only auto-discovers the default
testsource set. If you have custom Gradle source sets (intTest,manualTest) that share the same package names, only one set will appear. To work around this:com.example.unit,com.example.integration).Custom Test Configuration
You can explicitly tell the Java Test Runner where to find classes for each scope by adding entries to
java.test.configin your VS Codesettings.json. For example:This forces the Test Explorer to treat each scope separately.
File an Enhancement Request
Currently there’s no built-in support for multiple Gradle test source sets sharing the same package. You can open a feature request against the Java Test Runner:
https://github.com/microsoft/vscode-java-test/issues/new?assignees=&labels=&template=feature_request.md
Other references with low confidence
Support Gradle test delegation
The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!
wenytang-ms commentedon Mar 6, 2026
Hi mfarich we’ve released a prerelease version
0.44.2026030602oftest-runner-for-java, which fixes the issue you reported. Please install this version together with the latest prerelease ofvscode-gradleand help verify the fix.you may find the details in the PR, which contains the record about this fix

before
fixed

mfarich commentedon Mar 24, 2026
wenyt (@wenytang-ms) sorry for the delay, but yes this does seem to resolve the issue