Could not recognize different test set

I'm working on gradle project with the structure like below:

main
- java
- resource
test
- java
- resource
test-integration
- java
- resource

Java Test Runner can only recognize test on /test but not on /test-integration

quoccuongngo

Does the folder test-integration marked as test folder in the gradle configuration?

I have the same configuration and issue. The test runner does not see the integration tests unless i add the integration test directory to the test source sets but that behavior is undesirable since then gradle will run the integration tests with the regular unit tests.

I tried setting the test config option in my settings.json file to both of the below and that had no change.
"java.test.defaultConfig": "integrationTest" "java.test.defaultConfig": "integration-test"
Here is my build.gradle file. The behavior I expect is that since the task is a type "test" that the java test runner is able to recognize it as a seperate test configuration. Or that i can specify that integration tests is the test configuration i want to run.

sourceSets {
    main {
        java.srcDirs = ['src/main/java']
        resources.srcDirs= ['src/main/resources']
    }
    test {
        java.srcDirs = ['src/test/java']
	resources.srcDirs = ['src/test/resources']	
    }   
    integrationTest{      
        java.srcDirs = ['src/integration-test/java']      
        resources.srcDirs = ['src/integration-test/resources']
        compileClasspath += main.output +  test.output 
	runtimeClasspath += main.output + test.output 
    }
   
}
task integrationTest(type: Test) {
    testClassesDirs = sourceSets.integrationTest.output.classesDirs
    classpath = sourceSets.integrationTest.runtimeClasspath
    ignoreFailures = true
}

jbrandli

The behavior I expect is that since the task is a type "test" that the java test runner is able to recognize it as a seperate test configuration. Or that i can specify that integration tests is the test configuration i want to run.

jbrandli Can you explain more about this? Sorry I do not quite get your idea.

Right now, my integrationTests are not recognized by the java test runner, even though they are junit tests, and they have the gradle category of test.

I can make the java test runner recognize these tests by adding the integration-test directory to the "test" SourceSet configuration, but then i lose the ability to run my integration tests independently of the unit tests.

I would like the java test runner plugin to be able to recognize multiple source sets of tests.

I think the easiest option would be a setting for the extension that allows me to add another name for the test runner to look for.

"additionalTestConfigurations":["integrationTest"]

jbrandli

Thank you jbrandli for your feedback. I'll take a look.

has there been any development for this feature?

Another related issue: redhat-developer/vscode-java#2499

Seems that infer the test source paths according to the .classpath is not good enough.

My use case is very similar to this use case except that I am using maven and my tests are in src/main/java. This is because these tests are e2e tests using junit5 that we want to run any time our infrastructure changes. So we build them into a container and run that container as part of our CI/CD process. The test code itself rarely changes but the infra is changing constantly. It doesn't make conceptual sense to use the build process of different project to run tests across the entire application suite.

Gradle now has support for "JVM Test Suites" as a way to cleanly setup unit and integration tests separately. It would be great to see support for running or determining tests from different test suites.

https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html

I also just ran into this issue today with the same setup as the ticket description. Are there any workarounds, or planned solutions to this issue?

any news ?

any update? im facing the similar issue

I still have same issue

Try this

On your .vscode/settings.json

 "java.test.config": [
        {
            "name": "unitTest",
            "workingDirectory": "${workspaceFolder}",
            "args": [],
            "vmArgs": [
                "-Dspring.config.additional-location=file:${workspaceFolder}/src/test/resources/"
            ],
            "env": {},
            "sourcePaths": [
                "${workspaceFolder}/src/test"
            ],
            "classPaths": [
                "${workspaceFolder}/build/classes/java/test",
                "${workspaceFolder}/build/classes/java/main",
                "${workspaceFolder}/build/resources/test",
                "${workspaceFolder}/build/resources/main"
            ]
        },
        {
            "name": "integrationTest",
            "workingDirectory": "${workspaceFolder}",
            "args": [],
            "vmArgs": [
                "-Dspring.config.additional-location=file:${workspaceFolder}/src/integrationTest/resources/"
            ],
            "env": {},
            "sourcePaths": [
                "${workspaceFolder}/src/integrationTest"
            ],
            "classPaths": [
                "${workspaceFolder}/build/classes/java/integrationTest",
                "${workspaceFolder}/build/classes/java/test",
                "${workspaceFolder}/build/classes/java/main",
                "${workspaceFolder}/build/resources/integrationTest",
                "${workspaceFolder}/build/resources/test",
                "${workspaceFolder}/build/resources/main"
            ]
        },
    ],

In my case the integration tests is in a module named integrationTest

Brian NQC (@briannqc)

Hi Brian NQC (@briannqc), 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.

Define a custom source set and test task in your Gradle build so VS Code’s Test Runner can discover and run integration tests. For example in build.gradle:

sourceSets {
    integrationTest {
        java.srcDir 'src/test-integration/java'
        resources.srcDir 'src/test-integration/resources'
    }
}

configurations {
    integrationTestImplementation.extendsFrom testImplementation
    integrationTestRuntimeOnly.extendsFrom testRuntimeOnly
}

task integrationTest(type: Test) {
    description = 'Runs integration tests.'
    testClassesDirs = sourceSets.integrationTest.output.classesDirs
    classpath = sourceSets.integrationTest.runtimeClasspath
    shouldRunAfter test
}
check.dependsOn integrationTest

If you use Eclipse/Buildship under the hood (which VS Code’s Java extensions do), add the integrationTest configuration to the classpath container so the language server picks it up:
```
eclipse {
    classpath {
        plusConfigurations += configurations.integrationTestImplementation
    }
}
```
See Support additional Gradle configurations redhat-developer/vscode-java#1809 (comment)
After updating build.gradle, run the “Java: Clean Java Language Server Workspace” command in VS Code and reload the window.

Other references with low confidence

Support additional Gradle configurations

• Title: Support additional Gradle configurations
Description: projects with integrationTest source set aren’t recognized by IntelliSense or the language server by default.
URL: redhat-developer/vscode-java#1809

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!

Navigation Menu

Repository navigation

Could not recognize different test set #464

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Could not recognize different test set #464

Description

Activity

jdneo commented on Dec 2, 2018

jbrandli commented on Mar 19, 2019

jdneo commented on Mar 20, 2019

jbrandli commented on Mar 20, 2019

jbrandli commented on Mar 20, 2019

jdneo commented on May 16, 2019

gsiawGH commented on Nov 16, 2021

jdneo commented on Aug 1, 2022

lucastheisen commented on Nov 25, 2022

ikstewa commented on Dec 22, 2022

tehsven commented on Jun 28, 2023

Med-H commented on Oct 5, 2023

parthasaradhie commented on Oct 11, 2023

yunusemreayhan commented on Apr 9, 2025

BrunoSouzaPicinini commented on Oct 10, 2025

github-actions commented on Nov 12, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions