[issue9926] Wrapped TestSuite subclass does not get __call__ executed

Michael Foord report at bugs.python.org
Sat Sep 25 00:33:04 CEST 2010

Michael Foord <michael at voidspace.org.uk> added the comment:

On 24/09/2010 19:23, Martin v. Löwis wrote:
> Martin v. Löwis<martin at v.loewis.de>  added the comment:
>> Perhaps slightly ironically (for this particular bug report) is that
>> the change was introduced to support class and module level setUp and
>> tearDown (similar to the use-case it now blocks).
> FWIW, this issue arrived from pygresql, see TestSuite2 in
> http://tinyurl.com/2ap9t6d


Heh, well - allowing multiple testcases to share fixtures like expensive 
databases was one of the primary use cases given for introducing 
setUpModule and setUpClass.

>> A backwards compatible change would be to rename BaseTestSuite *back*
>> to TestSuite and give the current TestSuite a new name.
> That sounds good to me.

As I mentioned, the introduction of _wrapped_run to TestSuite has been 
released in Python 2.7 - so I don't think that we can pursue this option.

>> The disadvantage of this approach is that it is not uncommon for test
>> frameworks to create suites themselves - and doing this could 'break'
>> tests using class / module fixtures.
> You mean, for test suites that have been modified to explicitly
> support Python 2.7?

No, I just mean that directly creating test collections using TestSuite 
is a common thing for test frameworks to do. If the base TestSuite 
didn't support class / module fixtures then these test frameworks would 
no longer be able to use these features.

>> Any other suggestions or ideas?
> I think this would then be for python-dev to discuss.

I think the result tagging idea will work both as a bugfix for 2.7 and 
3.2. I'll work on a  patch and test. If it doesn't work we can take it 
to python-dev, but bearing in mind that we have to remain compatible 
with the released 2.7 as well (i.e. not changing the behaviour of 
TestSuite drastically).


Python tracker <report at bugs.python.org>

More information about the Python-bugs-list mailing list