The working directory is not set to folder opened in VS Code when it's unmanaged folder

[robaho]

The 'test runner' correctly finds the tests in all of the subprojects, and shows them grouped by subproject.

The issue is that when run, the working directly is set to the top-level workspaceFolder, not the subject folder. When running the tests with gradle, the working directory is the top of the subproject.

I would try to create a test config, but I would need a test config for each project in order to set workingDirectory correctly - but then I would also need to somehow configure which test config to use for each subproject.

It seems that when subprojects are being used, something like:

{
workingFolder = "${subprojectFolder}"
}

is necessary.

[jdneo]

I tried running a test case written like this:

@Test
void test() {
    System.out.println(System.getProperty("user.dir"));
}

And it prints the directory of the sub-project, not the root project. Could you share a sample project and your VS Code Java settings?

[robaho]

Attaching a full project that demonstrates the problem.

Here are some screenshots as well:

With vscode test runner:

and running via the gradle runner:

and the project

mytest.zip

[jdneo]

What if you do this:

0. Check if you didn't set the setting java.test.config at user level.
1. Close the workspace in VS Code
2. Remove all the .classpath, .project. .settings/ in your project folder, include the root folder and the subproject folder
3. Reopen the workspace

I tried on my Windows and the path is correct.

[robaho]

So you’re saying this worked for you? This is a brand new project. How does deleting all of these files help - the grade plugin will recreate them.

[jdneo]

It's not necessarily caused by them, I was just guessing.

I did one more try on my Mac, this time I directly open the attached project without modifying anything, and the path is correct.

Could you share your vscode settings? Did you set "workingDirectory": "${workspaceFolder}" in java.test.config?

[robaho]

When I remove the workingDirectory from java.test.config it works as expected. If you look at this issue, that item in the workspace is added as part of the default #797 (comment)

It seems this should not be part of the default configuration.

[robaho]

The problem is if I remove that configuration, then non-Gradle projects have the wrong working directory. I can add it as a workspace setting, but it seems this should just work. Maybe allow the setting but when it's a gradle project ignore it?

[jdneo]

The problem is if I remove that configuration, then non-Gradle projects have the wrong working directory.

By default, the working directory should be the directory of the project. Could you give some more information about the projects that are not working on your side?

[robaho]

I think I’ve explained it. If you have that setting in there then it doesn’t work with gradle sub projects. If you remove it then non-gradle projects have the wrong directory.

[jdneo]

Sorry, I cannot reproduce it, below is a screenshot for a multi-module Maven project.

I've left the global setting and workspace setting empty.

BTW, don't get me wrong. I'm willing this fix the bugs, I just need a way to reproduce it, otherwise I don't know where to start.

[robaho]

Do not use maven. It needs to be an “unmanaged project”

[jdneo]

I see. I can repro this issue for an “unmanaged project”.

Root cause is that the real project location of the “unmanaged project” is located in a 'hidden' place - the extension workspace.

We could fix this issue by add some handling logic for the unmanaged project. To set the working directory to the folder opened in VS Code, since that is the project root from users' perspective.