homepage

$ python3.3 -m unittest test.test_queue
Generates errors in the unit test code of the form
AttributeError: 'BaseQueueTest' object has no attribute 'type2test'

This bug is becouse of Lib/unittest/loader.py:107 . So a quick fix would be to inherit from unittest.TestCase only in the exposed classes; but probably using a class decorator is the best solution.

The decorator solution looks overly mind-boggling for this simple case.
BTW, I'm not sure we support calling our tests in this way, but it would be a good goal to, so I'm in favor of fixing these kinds of problems.

New changeset 118f7bdd631b by R David Murray in branch '3.2':
#14333: fix test_queue so it can be run via standard unittest test discovery.
http://hg.python.org/cpython/rev/118f7bdd631b
New changeset 3ea4d7adb3e7 by R David Murray in branch 'default':
Merge #14333: fix test_queue so it can be run via standard unittest test discovery.
http://hg.python.org/cpython/rev/3ea4d7adb3e7
New changeset 340053208864 by R David Murray in branch '2.7':
#14333: fix test_queue so it can be run via standard unittest test discovery.
http://hg.python.org/cpython/rev/340053208864 

Not only do I think we should support calling our tests via unittest, I think we should move in the direction of having regrtest be implemented via standard unittest hooks rather than the monster it currently is. That will take quite a bit of effort, though :)
Given that we are in fact using unittest, I think it is much clearer to follow the standard unittest pattern and have tests that are supposed to be run marked by subclassing TestCase, rather than by being explicitly nominated in boilerplate at the bottom. Certainly any new test files I write work that way (and I even explicitly use test discovery in test_email).

Yes, FWIW much of the standard library tests are callable this way without issue. I have patches that fix the discoverability of a few test modules. I'll submit these in another issue.