| msg96364 - (view) |
Author: Robert Collins (rbcollins) *  |
Date: 2009-12-13 22:19 |
| :!python -m unittest foo.test_suite Traceback (most recent call last): File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib/python2.6/runpy.py", line 34, in _run_code exec code in run_globals File "/usr/lib/python2.6/unittest.py", line 875, in main(module=None) File "/usr/lib/python2.6/unittest.py", line 816, in __init__ self.parseArgs(argv) File "/usr/lib/python2.6/unittest.py", line 843, in parseArgs self.createTests() File "/usr/lib/python2.6/unittest.py", line 849, in createTests self.module) File "/usr/lib/python2.6/unittest.py", line 613, in loadTestsFromNames suites = [self.loadTestsFromName(name, module) for name in names] File "/usr/lib/python2.6/unittest.py", line 605, in loadTestsFromName (obj, test)) TypeError: calling <function test_suite at 0x7f748dd6d7d0> returned <unittest.TestSuite tests=[<foo.TestTask testMethod=test_can_construct>, <foo.TestTask testMethod=test_can_construct>]>, not a test where foo.py: def test_suite(): loader = unittest.TestLoader() tests = loader.loadTestsFromName(__name__) result = loader.suiteClass() result.addTests(generate_scenarios(tests)) return result |
|
|
| msg98915 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-02-05 22:25 |
| What made you think that would work? In your example foo.test_suite is neither a test nor a suite but a function. |
|
|
| msg98918 - (view) |
Author: Robert Collins (rbcollins) * |
Date: 2010-02-05 23:11 |
| Its a common convention in zope.testing, trial, testtools, bzr, ... |
|
|
| msg98919 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-02-05 23:12 |
| So it's a feature request then... |
|
|
| msg98931 - (view) |
Author: Jean-Paul Calderone (exarkun) * |
Date: 2010-02-06 04:14 |
| Sounds like one. As far as the trial behavior goes, "trial foo.test_suite" won't work, but "trial foo" will call "foo.test_suite", if one is defined. |
|
|
| msg99021 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-02-07 21:39 |
| Is this needed as well as the load_tests protocol? If a test module defines a load_tests function that returns a test suite then the following creates the test suite from load_tests and executes that: python -m unittest modulename I don't think we need a test_suite protocol as well. |
|
|
| msg99173 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-02-10 16:00 |
| Use load_tests instead. |
|
|
| msg114471 - (view) |
Author: James Westby (james-w) |
Date: 2010-08-21 01:07 |
| Hi, I think this was misdiagnosed: from unittest.py in 2.6, loadTestFromName: elif hasattr(obj, '__call__'): test = obj() if isinstance(test, TestSuite): return test elif isinstance(test, TestCase): return TestSuite([test]) else: raise TypeError("calling %s returned %s, not a test" % (obj, test)) so it supports callables, such as the test_suite function that Rob is passing. Therefore I don't think this is a feature request, and "use load_tests" isn't an appropriate resolution. I haven't checked what 2.7 and later do, but going on the above my diagnosis of this is the following. 1. test_suite is correctly identified as a callable 2. It is called an returns a unittest.TestSuite 3. It is not matched as being a a TestSuite or a TestCase, and so the error is raised. The reason it is not matched is that when run as -m unittest, the unittest module is __main__, and so the TestSuite in the isinstance check is a unittest.TestSuite against a __main__.TestSuite, which won't match. Therefore I think this is a legitimate bug, in at least 2.6. Thanks, James |
|
|
| msg114698 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2010-08-22 19:50 |
| Well, it was misdiagnosed yes - but asking for "python -m unittest ..." support in Python 2.6 is still a feature request and not a bug report. (So unfortunately it can't be fixed in 2.6 which is bugfix only. The solution is to use unittest2 or Python 2.7.) |
|
|