-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
- a detailed description of the bug or problem you are having
- output of
pip listfrom the virtual environment you are using: pip-list.txt - pytest and operating system versions: Python 3.7.3, pytest-6.2.5, OSX 10.15.7
- minimal example if possible
I've noticed some odd behavior happening when __init__.py files are explicitly included as arguments to pytest--specifically, it seems that this causes the first (alphabetically) test file in the directory of the __init__.py file to be collected twice. This is quite odd behavior--it will be easier to just specify an example.
Consider the following directory structure:
.
└── test_module
├── __init__.py
└── all_tests.py
1 directory, 2 files
The __init__.py file is empty, and the all_tests.py file contains one trivial test:
def test_works():
assert 1 == 1With this setup, we run pytest -vv ./test_module/__init__.py ./test_module/all_tests.py, and get the following output:
platform darwin -- Python 3.7.3, pytest-6.2.5, py-1.10.0, pluggy-1.0.0 -- /Users/andremenck/repos/brex/credit_card/python/venv/bin/python
cachedir: .pytest_cache
rootdir: /Users/andremenck/repos/brex/repro_pytest
plugins: celery-4.4.6, grpc-0.8.0, vcr-1.0.2, rerunfailures-10.2, stub-1.1.0, ordering-0.6
collected 2 items
test_module/all_tests.py::test_works PASSED [ 50%]
test_module/all_tests.py::test_works PASSED [ 50%]
================================================================================== 2 passed in 0.01s ==================================================================================
As you can see, the all_tests.py test executes twice. We can further confirm that this is in fact running twice by adding a statefull side-effect to test_works, as follows:
i = 0
def test_works():
global i
assert i == 0
i += 1
Now when pytest -vv ./test_module/__init__.py ./test_module/all_tests.py is invoked, the second execution of the test will fail, confirming that this test is being run twice.
I understand that including __init__.py explicitly in a pytest call is probably not standard/not a fantastic idea (in fact, the simplest resolution here for me was just to not include these files explicitly). However, it seems to me that this shouldn't be causing the behavior seen above. Am I correct, or is this kind of behavior expected?