Pytest args --rootdir is broken

[FelixBenning]

Due to the usage of docker-compose my python app is in a subdirectory of the workspace therefore I want to do something like this:

  "python.testing.pytestArgs": [
    "--rootdir=/composeDir/app",
    "tests"
  ],
  "python.testing.cwd": /composeDir/app

but this does not work as expected. Since the --rootdir option is passed to pytest by default with the workspace location, vscode executes this

python /root/.vscode-server/extensions/ms-python.python-2021.4.765268190/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir /composeDir -s --cache-clear /composeDir/manager

In other words the custom rootdir option becomes the argument and "tests" is completely ignored.

[karthiknadig]

Can you try separating the arguments? we might be trying to look for --rootdir.

"python.testing.pytestArgs": [
    "--rootdir",
    "/composeDir/app",
    "tests"
  ],

[g-as]

@karthiknadig this is because rootdir is handled internally (see here), and thus it cannot be modified.

See #9553, #14795, #10827 (same type of issue)

[thomassajot]

I am also experiencing this issue (original issue #14795).
It would be great to have a solution or a workaround to this feature !

[leelhn2345]

I am also experiencing this issue (original issue #14795).
It would be great to have a solution or a workaround to this feature !

I'm having the same issue too. The current workaround that I found is having 'conftest.py' in the project root.

[bhrutledge]

Copied from #9553 (comment)

During test discovery and running tests, it seems that --rootdir takes precedence over any positional arguments. It's not clear why this behavior exists, but it looks like it was added in June 2018 by @DonJayamanne, and moved in Aug 2021.

vscode-python/src/client/testing/testController/pytest/arguments.ts

Lines 137 to 141 in b6c0d3e

	export function pytestGetTestFolders(args: string[]): string[] {
	const testDirs = getOptionValues(args, '--rootdir');
	if (testDirs.length > 0) {
	return testDirs;
	}

Looking at the pytest docs for rootdir, I don't think this is the correct behavior. IE, I don't think --rootdir is necessarily (or even frequently) the equivalent of a directory containing tests; it should be the directory that contains pytest.ini, which is frequently the parent directory of a tests directory.

My naive suggestion would be to remove the --rootdir processing from pytestGetTestFolders, and assume the user has configured at least one of:

• Test paths in python.testing.pytestArgs
• python.testing.cwd
• testpaths in pytest.ini

[tbridel]

Hi everyone,

I am just posting what worked for me since I had the same issue and Google landed me here.
I tried setting python.testing.cwd, --rootdir manually in python.testing.pytestArgs, putting a pytest.ini file in the parent folder ... those solutions did not work.
What worked for me is to add the following section:

[tool:pytest]
testpaths=
    relative_path_to_the_first_folder/test
    relative_path_to_the_second_folder/test

in the setup.cfg file that I (already) had at the root of my workspace folder, i.e.

setup.cfg
VERSION
...
folder1
|- toto.txt
|- ...
relative_path_to_the_first_folder
|- setup.py
|- test
|-- test_1.py
|-- test_2.py
|- module_code
|-- module_source_1.py
|-- module_source_2.py
...

Then I Cmd + Shift + P and invoked Pytest: Configure Tests, telling it to follow the pre-existing setup.cfg, and it fixed the erratic behaviour described in this ticket.

Cheers !

[eleanorjboyd]

Hello! We have just finished our testing rewrite and are beginning the roll out to users. If you are able, it would be very helpful to know if your issue still exists on the rewrite! To try it yourself, add this setting to your users settings.json "python.experiments.optInto": ["pythonTestAdapter"].

You can confirm you have the rewrite enabled by setting "python.analysis.logLevel": "Trace", in your user settings then check for Experiment 'pythonTestAdapter' is active in your python logs.

I have tried --rootdir and it has worked but want to know for your specific case, Thanks!

[github-actions]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!