Skip to content

Gradle and VS Code - Test Explorer panel Issue #1835

Closed

Description

@mfarich

(about info)
Version: 1.109.2 (user setup)
Commit: 591199df409fbf59b4b52d5ad4ee0470152a9b31
Date: 2026-02-10T20:18:23.520Z
Electron: 39.3.0
ElectronBuildId: 13168319
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

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.

repro-vscode-testing.zip

Activity

  1. github-actions commented on Feb 12, 2026

    @github-actions

    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:

      "java.test.config": [
        {
          "name": "unit Tests",
          "buildCommand": "./gradlew testClasses",
          "testKind": "junit",
          "cwd": "${workspaceFolder}",
          "classPaths": ["build/classes/java/test"]
        },
        {
          "name": "integration Tests",
          "buildCommand": "./gradlew intTestClasses",
          "testKind": "junit",
          "cwd": "${workspaceFolder}",
          "classPaths": ["build/classes/java/intTest"]
        },
        {
          "name": "manual Tests",
          "buildCommand": "./gradlew manualTestClasses",
          "testKind": "junit",
          "cwd": "${workspaceFolder}",
          "classPaths": ["build/classes/java/manualTest"]
        }
      ]

      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!

  2. wenytang-ms commented on Mar 6, 2026

    @wenytang-ms
    Contributor

    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
    Image

    fixed
    Image

  3. mfarich commented on Mar 24, 2026

    @mfarich
    Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions