[Vinay Kumar Maheshwaram (sudovinay01)]

Why this is needed

The Java Test Runner currently discovers test files from source roots classified as test roots by the Java project model. In Gradle projects, src/main/java remains a main source root, so TestNG classes there can compile but are not discovered for editor test actions or Test Explorer. Reclassifying that directory as a Gradle test source set would change build semantics and is not appropriate for projects that intentionally keep these classes in main sources.

IntelliJ IDEA and Eclipse already discover tests in both main and test source folders and provide run/debug actions for them. This change brings that IDE-level discovery capability to VS Code as an opt-in, without changing Gradle source-set classification or task behavior.

What this changes

• Adds the opt-in, workspace-scoped java.test.additionalTestSourcePaths setting. Its default is an empty array, preserving existing behavior.
• Accepts literal source paths or workspace-relative glob patterns and expands glob matches into source directories. The glob library is declared as a production dependency.
• Includes resolved roots in source-path checks and file watching, scans existing Java files with bounded concurrency, and applies Test Explorer updates sequentially.
• Clears cached paths and rebuilds discovery when this setting changes or the user refreshes the Testing view. Overlapping refresh requests are serialized to avoid watcher races.
• Uses stable workspace URI keys, ignores nonexistent literal directories, reports glob errors in the Test Runner for Java Output channel, and deduplicates roots.
• Logs a heads-up when patterns match more than 100 directories; no hard limit is imposed.
• Does not modify Gradle source-set configuration or task behavior.

Configuration example

{
  "java.test.additionalTestSourcePaths": ["app/**/src/main/java"]
}

Reproducer

The manual acceptance project is available at https://github.com/sudovinay01/repro-java-issue.

Validation

• npm test: 165 extension tests passed; activation test passed.
• npm run lint passed.
• Production webpack bundle compiled successfully.
• Regression tests verify additional roots are watched and overlapping refresh requests are serialized.
• Manual reproducer check: AppMainSourceTest and AppTest appeared in Test Explorer and both passed (2/2).

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Vinay Kumar Maheshwaram (sudovinay01)]

Vinay Kumar Maheshwaram (Vinay Kumar Maheshwaram (@sudovinay01)) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

[Vinay Kumar Maheshwaram (sudovinay01)]

Could a maintainer please help triage this PR or assign a reviewer when available? It has been open since September 26, and I would appreciate guidance on whether any changes are needed before review. Thank you.

[Vinay Kumar Maheshwaram (sudovinay01)]

Merged current upstream main into this branch in fcb779f and regenerated package-lock.json from the merged manifest, preserving glob as a production dependency. Validation passed: npm ci, npm run compile, npm run lint, npm run vscode:prepublish, npm run build-plugin, and npm test (165 extension tests plus the unmanaged-folder test). GitHub now reports the PR as mergeable.

[Vinay Kumar Maheshwaram (sudovinay01)]

Hi Jinbo Wang (@testforstephen) Changyong Gong (@chagong) wenyt (@wenytang-ms) — could one of you please review this PR when you have time? I’d appreciate feedback on the change and validation, and I’d like to make sure it aligns with the project’s expectations. Thanks for your time and review.

[wenyt (wenytang-ms)]

Thanks Vinay Kumar Maheshwaram (@sudovinay01) for raising this use case and contributing the implementation! Supporting test discovery in main source roots makes sense without requiring users to change their build configuration. The following design aspects need to be adjusted before this can be merged:

1. Unify discovery scope: The client includes additional paths, but project-level discovery on the Java backend still uses the original test roots. Subsequent project refreshes could remove tests discovered by the client.
2. Keep related features consistent: Editor actions, Test Explorer, and "Go to Test" should use the same discovery scope. The current implementation only extends the client-side paths.
3. Avoid a separate full-file scanning pipeline: Scanning every Java file during activation and refresh adds potentially significant overhead. Concurrency limits do not bound the total work, and cancellation is not supported. This should integrate with backend project-level discovery.
4. Clarify configuration boundaries: Additional discovery paths should be limited to source roots already included in imported Java projects. The setting should explicitly state that it does not configure source roots, dependencies, or compilation outputs.
5. Narrow the configuration scope: Arbitrary paths and glob patterns introduce long-term complexity around directory changes, overlapping roots, multi-module projects, and performance. We should first establish whether a simpler option to include existing main source roots is sufficient.

The discovery scope should be defined consistently in the Java backend, rather than maintained through a separate client-side scanning path.

[Vinay Kumar Maheshwaram (sudovinay01)]

wenyt (@wenytang-ms) Thanks for the detailed feedback. I have updated the PR to address these points: project-level test discovery now runs through the Java backend and includes selected additional source roots, with the same resolved scope used for Test Explorer, editor actions, file watching, and Go to Test. The separate client-side Java-file scan has been removed; configured literals/globs are intersected with source roots from imported Java projects, and the setting description clarifies that discovery does not change source roots or build configuration. I retained glob support for selecting roots in multi-module projects, with duplicate matching roots deduplicated. Validation now includes npm run compile, npm run lint, npm test (170 tests plus the unmanaged-folder test), npm run vscode:prepublish, the Java plugin build, and manual Test Explorer checks (5/5 tests, refresh, file create/change/delete, and unmatched-path refresh). The updated implementation is in commit b0589ee.