Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python -m unittest path_to_suite_function errors #51750

Closed
rbtcollins opened this issue Dec 13, 2009 · 9 comments
Closed

python -m unittest path_to_suite_function errors #51750

rbtcollins opened this issue Dec 13, 2009 · 9 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@rbtcollins
Copy link
Member

BPO 7501
Nosy @rbtcollins, @voidspace

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2010-02-10.16:00:19.453>
created_at = <Date 2009-12-13.22:19:50.909>
labels = ['type-bug', 'library']
title = 'python -m unittest path_to_suite_function errors'
updated_at = <Date 2010-08-22.19:50:23.486>
user = 'https://github.com/rbtcollins'

bugs.python.org fields:

activity = <Date 2010-08-22.19:50:23.486>
actor = 'michael.foord'
assignee = 'none'
closed = True
closed_date = <Date 2010-02-10.16:00:19.453>
closer = 'michael.foord'
components = ['Library (Lib)']
creation = <Date 2009-12-13.22:19:50.909>
creator = 'rbcollins'
dependencies = []
files = []
hgrepos = []
issue_num = 7501
keywords = []
message_count = 9.0
messages = ['96364', '98915', '98918', '98919', '98931', '99021', '99173', '114471', '114698']
nosy_count = 4.0
nosy_names = ['exarkun', 'rbcollins', 'michael.foord', 'james-w']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue7501'
versions = ['Python 2.6', 'Python 3.1', 'Python 2.7', 'Python 3.2']

@rbtcollins
Copy link
Member Author

:!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 <module>
    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

@rbtcollins rbtcollins added type-crash A hard crash of the interpreter, possibly with a core dump stdlib Python modules in the Lib dir labels Dec 13, 2009
@bitdancer bitdancer added type-bug An unexpected behavior, bug, or error and removed type-crash A hard crash of the interpreter, possibly with a core dump labels Dec 13, 2009
@voidspace
Copy link
Contributor

What made you think that would work? In your example foo.test_suite is neither a test nor a suite but a function.

@rbtcollins
Copy link
Member Author

Its a common convention in zope.testing, trial, testtools, bzr, ...

@voidspace
Copy link
Contributor

So it's a feature request then...

@exarkun
Copy link
Mannequin

exarkun mannequin commented Feb 6, 2010

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.

@voidspace
Copy link
Contributor

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.

@voidspace
Copy link
Contributor

Use load_tests instead.

@james-w
Copy link
Mannequin

james-w mannequin commented Aug 21, 2010

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

@voidspace
Copy link
Contributor

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.)

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants