-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Pytest performs collection under cwd rather than under specified rootdir #10665
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
rootdir is only used to determine test nodeids (relative to rootdir) its not informing a default set of tests the testpaths option sets the default seach path |
Yes this corresponds to my description of the behaviour I'm seeing. Is there any reason it makes more sense for rootdir to have no impact on where collection takes place and for it to only be done via Do you have any suggestions for a solution to the problem I described with implementing a wrapper script? |
You can pass testpaths in via the cli using option overrides |
Ahh so |
Actually this doesn't quite work - it seems the If I add the following in def pytest_addoption(parser: pytest.Parser):
parser.addoption("--foo", action="store_true", help="foo") then I get:
whereas this works if I also pass e.g. |
pytest-addoption can only be used in the conftests directly under the rootdit/config dirs (as pytest will only look at the root ones before parsing ci args |
Hmm but in the example above the rootdir is This works: This does not work: Even though both cases have the same rootdir. |
I can confirm the issue @LewisGaul is reporting. I think this issue should be re-opened. |
Had to hard-code test folder in invokation since pytest fails to recognize subfolders configured with testpaths parameter. Refs: pytest-dev/pytest#10665
the title needs to change tho, but im not sure abou what would be best |
Waiting for pytest-dev/pytest#10665 to be addressed.
Closing as a duplicate of #9311. |
pytest-dev/pytest#10665 has been replaced by pytest-dev/pytest#9311
When specifying
--rootdir
(or using-c
to give a config file that might implicitly be used to determine the root dir?), pytest still collects tests under the current working directory, rather than under the specified root.This means that at least one of the following conditions must be met to avoid pytest searching in the wrong place:
pytest <path_to_dir>
Say we have a test package structured as follows:
Then from any cwd it's possible to run
pytest /some/path/to/tests/
to run all the tests, orpytest /some/path/to/tests/sub1/
to run a specific subpackage. The problem is that there's no way to run from another cwd without specifying<path_to_dir>
, e.g. it cannot be specified aspytest --rootdir=/some/path/to/tests/
since pytest will then search cwd.The problem with this is it makes it hard to write a convenience wrapper script supporting
run-my-tests [<file_or_dir>] [<other_pytest_args>]
, where if no args are passed it should run all the tests, or if<file_or_dir>
is given as a path relative to cwd then only those specified tests will be run. That is, I want to support the following:<file_or_path>
) withrun-my-tests <args>
->pytest /some/path/to/tests/ <args>
/some/path/to/
) Run a specified subset of tests withrun-my-tests tests/sub1/ <args>
->pytest tests/sub1/ <args>
Given point 2 supporting relative paths, the wrapper cannot change cwd. However, under point 1, the wrapper script must pass the test root dir, and if this dir is always passed then all the tests will always be run (ignoring sub-paths that may be passed as in point 2). There is no general way for the wrapper script to know whether a path has been given (checking args to see if they look like a path is not foolproof unless reimplementing full parsing of pytest args, which is not even possible in the case of arbitrary plugins adding args).
The request is for pytest to only search for tests under the rootdir, i.e. the wrapper described above could be implemented as simply adding
--rootdir=/some/path/to/tests/
, which would satisfy the two cases above.The text was updated successfully, but these errors were encountered: