Message162374
Suppose you have a test package:
test_pkg
__init__.py
test_mytest.py
If __init__.py is empty and you run
python -m unittest test_pk
no tests are found.
You can get this to work by adding the following boiler plate to __init__.py:
def load_tests(loader, standard_tests, pattern):
this_dir = os.path.dirname(__file__)
if pattern is None:
pattern = "test*"
package_tests = loader.discover(start_dir=this_dir,
pattern=pattern,
top_level_dir=this_dir)
standard_tests.addTests(package_tests)
return standard_tests
Note that top_level_dir is required to handle specifying more than one test package at a time on the unittest command line. Otherwise the second package gets a loader that already has _top_level_dir set, and so it fails to default to start_dir. I suspect this is also a bug.
This works; it uses discovery to find the tests and returns them using the load test protocol. Other methods could be used to construct the test to add as well. But all have the serious disadvantage that the package name does not appear in the output. Running the above test_pkg command line give results like this with -v:
test_something (test_mytest.Test) ... ok
test_pkg is not mentioned. This is merely annoying when running a single test package, but if you
do something like:
python -m unittest -v test_pkg test_pkg2
You can't tell in the verbose output or the test failure output which
test package the tests are from.
In summary, unittest needs better support for test packages. |
|
Date |
User |
Action |
Args |
2012-06-05 21:20:29 | r.david.murray | set | recipients:
+ r.david.murray, michael.foord |
2012-06-05 21:20:29 | r.david.murray | set | messageid: <1338931229.09.0.80724559879.issue15007@psf.upfronthosting.co.za> |
2012-06-05 21:20:28 | r.david.murray | link | issue15007 messages |
2012-06-05 21:20:26 | r.david.murray | create | |
|