[Python-Dev] setUpClass and setUpModule in unittest

[Nick Coghlan]

R. David Murray wrote:
> would be easier to write, be more maintainable, and be easier to
> understand when reading the code than the equivalent setUp and tearDown
> methods would be.
> 
> I'm not saying it would be easy to implement, and as you say backward
> compatibility is a key concern.

That's the gist of my thinking, yeah.

However, a couple of problems of note that occurred to me after an extra
day or so of musing on the topic:
- the semantics I listed in my original post are broken, since a naive
context manager couldn't be used (it would setup and tear down the
resources for each test instance, which is what we're trying to avoid).
Supporting naive context managers would require iterating over the test
classes within the module CM and iterating over the instances within the
class CM.
- context managers fit best in more procedural code. They're tricky to
invoke correctly from code that is split across several methods in
different classes (as I believe unittest is), since you can't use a with
statement directly to do the invocation for you

So I think new setup*/teardown* methods and functions are likely to be a
better fit for the unittest architecture. At a later date, it may be
worth adding some mixins or other mechanisms that adapt from the
unittest setup/teardown model to a CM based model, but to be honest, if
I want to use a CM when testing, I'll generally create a more complex
test method that iterates through a bunch of test inputs itself.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------