The very common directory structure for even a simple Python module seems to be to separate the unit tests into their own test
directory:
new_project/ antigravity/ antigravity.py test/ test_antigravity.py setup.py etc.
for example see this Python project howto.
My question is simply What's the usual way of actually running the tests? I suspect this is obvious to everyone except me, but you can't just run python test_antigravity.py
from the test directory as its import antigravity
will fail as the module is not on the path.
I know I could modify PYTHONPATH and other search path related tricks, but I can't believe that's the simplest way - it's fine if you're the developer but not realistic to expect your users to use if they just want to check the tests are passing.
The other alternative is just to copy the test file into the other directory, but it seems a bit dumb and misses the point of having them in a separate directory to start with.
So, if you had just downloaded the source to my new project how would you run the unit tests? I'd prefer an answer that would let me say to my users: "To run the unit tests do X."
Tests are defined as functions prefixed with test_ and contain one or more statements that assert code produces an expected result or raises a particular error. Tests are put in files of the form test_*. py or *_test.py , and are usually placed in a directory called tests/ in a package's root.
The best solution in my opinion is to use the unittest
command line interface which will add the directory to the sys.path
so you don't have to (done in the TestLoader
class).
For example for a directory structure like this:
new_project ├── antigravity.py └── test_antigravity.py
You can just run:
$ cd new_project $ python -m unittest test_antigravity
For a directory structure like yours:
new_project ├── antigravity │ ├── __init__.py # make it a package │ └── antigravity.py └── test ├── __init__.py # also make test a package └── test_antigravity.py
And in the test modules inside the test
package, you can import the antigravity
package and its modules as usual:
# import the package import antigravity # import the antigravity module from antigravity import antigravity # or an object inside the antigravity module from antigravity.antigravity import my_object
Running a single test module:
To run a single test module, in this case test_antigravity.py
:
$ cd new_project $ python -m unittest test.test_antigravity
Just reference the test module the same way you import it.
Running a single test case or test method:
Also you can run a single TestCase
or a single test method:
$ python -m unittest test.test_antigravity.GravityTestCase $ python -m unittest test.test_antigravity.GravityTestCase.test_method
Running all tests:
You can also use test discovery which will discover and run all the tests for you, they must be modules or packages named test*.py
(can be changed with the -p, --pattern
flag):
$ cd new_project $ python -m unittest discover $ # Also works without discover for Python 3 $ # as suggested by @Burrito in the comments $ python -m unittest
This will run all the test*.py
modules inside the test
package.
The simplest solution for your users is to provide an executable script (runtests.py
or some such) which bootstraps the necessary test environment, including, if needed, adding your root project directory to sys.path
temporarily. This doesn't require users to set environment variables, something like this works fine in a bootstrap script:
import sys, os sys.path.insert(0, os.path.dirname(__file__))
Then your instructions to your users can be as simple as "python runtests.py
".
Of course, if the path you need really is os.path.dirname(__file__)
, then you don't need to add it to sys.path
at all; Python always puts the directory of the currently running script at the beginning of sys.path
, so depending on your directory structure, just locating your runtests.py
at the right place might be all that's needed.
Also, the unittest module in Python 2.7+ (which is backported as unittest2 for Python 2.6 and earlier) now has test discovery built-in, so nose is no longer necessary if you want automated test discovery: your user instructions can be as simple as python -m unittest discover
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With