[issue15007] Unittest CLI does not support test packages very well
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15007] Unittest CLI does not support test packages very well
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15007] Unittest CLI does not support test packages very well
New submission from R. David Murray rdmur...@bitdance.com: 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. -- messages: 162374 nosy: michael.foord, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Unittest CLI does not support test packages very well type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15007] Unittest CLI does not support test packages very well
Michael Foord mich...@voidspace.org.uk added the comment: Whilst I agree in principle... The trouble is that when you do this: python -m unittest test_pk What you are saying is run all the tests from the test_pk module. You *aren't* launching discovery. This should work: python -m unittest discover -t . test_pkg This is more verbose than is ideal. Suggestions for improvements welcome. Having unittest revert to discovery when it is passed a package name that turns out to be empty seems a bit magical (and complex in terms of implementation). Yes, calling loader.discover inside a load_tests function will mutate that loader - so having discover restore _top_level_dir on exit would be better. Can you post that as a separate issue? I think there is a separate issue for improving the test failure name (including module) reporting. I'll try and dig out the issue number. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15007] Unittest CLI does not support test packages very well
R. David Murray rdmur...@bitdance.com added the comment: Right, I'm not wanting to run discovery from the command line, I'm wanting to run the tests in the package by package name. In my mind, this is exactly parallel to specifying a module name and having unittest automatically discover the TestCase classes in it. We don't have unittest run 0 tests because discovery wasn't invoked when the module name was specified. Why should it be different for a test package? If boilerplate is required in __init__.py to make that happen that's OK, though to my mind not ideal. Is there some different magic I can put into __init__.py that will result in the tests in the package being run such that the package name shows up in the report? Without that, specifying a package name on the unittest command line seems pretty useless. (I mean, to get it to do anything useful, you'd have to be putting all the TestCases in the __init__.py, and if you are doing that, why have a package?) The issue about improving the name output was about making it copy and pasteable (something I would also very much like). The naming issue here is different, about how to get the package name to show up in the fully qualified test name. I will open another bug for the _top_level_dir issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
