Open mattalxndr opened 2 years ago
I can reproduce. No idea why it's happening, though.
@The-Compiler I narrowed it down to this block here:
But I don't know enough about the codebase to know what it should be doing.
This has been added in d632a0d5c26c7c988a592e6b5a585685a576e36a, and while I agree it is surprising, it is a documented feature:
if exists, load conftest.py and test*/conftest.py relative to the directory part of the first test path.
So unless we want to somehow change this (including a deprecation period), we can close this as "worked as intended".
That commit only moves the code around - it was initially added in 7bd60b5abb66e10cb107f79e412bfbb576e84b8b some 12 years ago:
check and load test*/conftest.py early from anchors - this makes it a bit more convenient to have command line options available from a root directory of a project that does not directly contain a conftest.py
The testpaths
option was only added 5 years later, in 854e603f84dde8345cd959ad302ddb5d281e67b2. It seems reasonable to me to use that setting (if set) rather than assuming test*
blindly. Still probably a backwards-incompatible change though.
Reading the code, using testpaths
is not right here -- the testpaths themselves are iterated and used as anchors for try_load_conftest
- i.e. the idea seems to be "let's also consider test* subdirs
" inside of each testpath.
Hmm, sorry, I might be confusing the variable name testpaths
with the config testpaths
. Disregard the above :)
This has been added in d632a0d, and while I agree it is surprising, it is a documented feature:
if exists, load conftest.py and test*/conftest.py relative to the directory part of the first test path.
So unless we want to somehow change this (including a deprecation period), we can close this as "worked as intended".
Is this really expected behaviour? I'm in doubt so I'll share my setup using pytest 7.0.0:
├── lambda_layer
│ ├── layer.zip
│ └── python
│ ├── numpy
│ │ └── conftest.py <--
├── pytest.ini
├── src
│ ├── mycodehere.py
├── tests
│ └── test_my_test_code_here.py
pytest.ini looks like this:
[tool:pytest]
addopts = -m 'not e2e'
testpaths = tests
When I execute pytest
it fails, because numpy's conftest wants to import dependencies that I don't have installed. (I don't want to install those dependencies, I'm making a lambda layer, so those files are maybe there or maybe not, but it feels like it should not load all conftests under my repo root when I have specified testpaths)
Is this really expected behaviour?
if exists, load conftest.py and test*/conftest.py relative to the directory part of the first test path
Isn't my first test path tests
as specified via testpaths in my pytest.ini? I guess when reading the manual regarding testpaths it does not really say anything about conftest loading behaviour. What to do with this?
Is this really expected behaviour?
@dhensen this seems like a different problem, because lambda_layer
doesn't match tests*
.
@dhensen, in your pytest.ini
, it should be only [pytest]
in the header, [tool:pytest]
is only used for setup.cfg
files.
I'm not sure why this is a feature though because I would expect running pytest tests/
and using testpaths = tests
when running pytest
without any arguments to have the same behaviour, I thought that was the point of testpaths
.
I'm not sure why this is a feature though because I would expect running pytest tests/ and using testpaths = tests when running pytest without any arguments to have the same behaviour, I thought that was the point of testpaths.
I agree, seems like that feature was introduced prior to testpaths
.
I guess it is possible to deprecate the behavior: we can detect a conftest.py
was matched via test*/conftest.py
, and issue a deprecation warning.
pip list
from the virtual environment you are usingI am defining
testpaths = tests
inpytest.ini
and that's being picked up by pytest (see pytest output below), but then it's loading aconftest.py
from another directory.Reproduction steps
Environment setup
The test files:
Their contents:
The command:
What I expect to see
What I actually see
Of note
If I
mv testsinvalid anything-without-the-prefix-tests
, the problem goes away.