In Python 3.2, when inheriting from TestSuite, it is no longer possible to override __call__ (e.g. to introduce a TestSuite setUp and tearDown).
The __call__ method will not be called anymore.

Instead, if the object has a _wrapped_run defined (which it will, since it inherits from TestSuite), then this is called instead. Overriding _wrapped_run is a work-around, however, this being a private method, overriding it is probably not a good idea.

Right, _wrapped_run is private and not intended to be overridden. 

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

Another workaround would be to inherit from BaseTestSuite (which would disable the class and module level fixture support).

A backwards compatible change would be to rename BaseTestSuite *back* to TestSuite and give the current TestSuite a new name. This means that the new class / module level fixtures would only be supported in code that gets suites from the TestLoader (which uses the new class) or by creating suites using the new class.

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.

The reason for the change is that in order to tearDown the final class and module level fixtures we need to know when we exit the 'top level' of a run from inside a suite.

Any other suggestions or ideas?

(Another idea is to add explicit setUp and tearDown hooks to the TestSuite object. This isn't backwards compatible but meets the direct use case. Obviously backwards compatibility is greatly preferable.)

Hmmm... 2.7 has already been released and has the same issue, so 'drastic' changes (like renaming BaseTestSuite back to TestSuite) are probably out.

Ok, so here is an idea that could remove the need for TestSuite._wrapped_run. 

TestSuite.run could "tag" the result object (set an attribute). Nested TestSuites would see an already tagged suite and do nothing (beyond running tests of course). The suite that does the tagging would call the necessary module / class level test suites on exit.

> 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

Here, the objective is to wrap a number of test suite classes
with a single setup/teardown, covering all test cases that occur
in either test suite, so that the expensive database creation
happens only once. I can't see how either class or module level
setup could easily replace this.

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

> 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?

> Any other suggestions or ideas?

I think this would then be for python-dev to discuss.

On 24/09/2010 19:23, Martin v. Löwis wrote:
> Martin v. Löwis<martin@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

Thanks.

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

The attached patch fixes the issue (I think...) by tagging the result object. It removes the need for _wrapped_result altogether. The test fails without the change to TestSuite and passes with the change.

This could be applied to 2.7-maint and py3k.

Uhm... the patch needs a better name for the TestResult tag attribute.

Committed to py3k in revision 86101. Needs porting to Python 2.7 (and unittest2).

Committed to release27-maint in revision 86104.