`python -m unittest discover` does not discover tests
Question:
Python’s unittest discover does not find my tests!
I have been using nose to discover my unit tests and it is working fine. From the top level of my project, if I run nosetests I get:
Ran 31 tests in 0.390s
Now that Python 2.7 unittest has discovery, I have tried using
python -m unittest discover
but I get
Ran 0 tests in 0.000s
My directory structure is:
myproj/
reporter/
__init__.py
report.py
[other app modules]
tests/
__init__.py
test-report.py
[other test modules]
Do you have any ideas why unittest’s discovery algorithm can’t find the tests?
I’m using Python 2.7.1 and nose 1.0.0 on Windows 7.
Answers:
The behaviour is intentional, but the documentation could make this clearer. If you look at the first paragraph in the test discovery section, it says:
For a project’s tests to be compatible with test discovery they must all be importable from the top level directory of the project (in other words, they must all be in Python packages).
A corollary to that is that the file names must also be valid Python module names. test-report.py fails that test, since test-report is not a legal Python identifier.
A docs bug suggesting that this be mentioned explicitly in the documentation for the -p pattern option would probably be a good way forward.
As someone relatively new to Python, the naming convention in the docs implied the opposite. Ben’s comment was very helpful: the default discovery pattern looks for test-modules prefixed with the string “test”
I thought the introspection would just look for class names and not require a specific file naming convention.
Here is what the docs say:
https://docs.python.org/3/library/unittest.html
python -m unittest discover -s project_directory -p “_test.py”
I couldn’t get this to work, but by changing my file names to be “test_.py” – success!
I had this problem because some directories in a project were missing __init__.py. I thought I don’t need them in Python 3.7.
Just add __init__.py to every directory and python3 -m unittest will find tests automatically.
Python’s unittest discover does not find my tests!
I have been using nose to discover my unit tests and it is working fine. From the top level of my project, if I run nosetests I get:
Ran 31 tests in 0.390s
Now that Python 2.7 unittest has discovery, I have tried using
python -m unittest discover
but I get
Ran 0 tests in 0.000s
My directory structure is:
myproj/
reporter/
__init__.py
report.py
[other app modules]
tests/
__init__.py
test-report.py
[other test modules]
Do you have any ideas why unittest’s discovery algorithm can’t find the tests?
I’m using Python 2.7.1 and nose 1.0.0 on Windows 7.
The behaviour is intentional, but the documentation could make this clearer. If you look at the first paragraph in the test discovery section, it says:
For a project’s tests to be compatible with test discovery they must all be importable from the top level directory of the project (in other words, they must all be in Python packages).
A corollary to that is that the file names must also be valid Python module names. test-report.py fails that test, since test-report is not a legal Python identifier.
A docs bug suggesting that this be mentioned explicitly in the documentation for the -p pattern option would probably be a good way forward.
As someone relatively new to Python, the naming convention in the docs implied the opposite. Ben’s comment was very helpful: the default discovery pattern looks for test-modules prefixed with the string “test”
I thought the introspection would just look for class names and not require a specific file naming convention.
Here is what the docs say:
https://docs.python.org/3/library/unittest.html
python -m unittest discover -s project_directory -p “_test.py”
I couldn’t get this to work, but by changing my file names to be “test_.py” – success!
I had this problem because some directories in a project were missing __init__.py. I thought I don’t need them in Python 3.7.
Just add __init__.py to every directory and python3 -m unittest will find tests automatically.