[Python-ideas] Test Class setup and teardown in unittest

[Mark Roddy]

On Wed, Jan 20, 2010 at 8:37 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> On Wed, 2010-01-20 at 19:38 -0500, Mark Roddy wrote:
>> Earlier this week on the Testing In Python list, there was a
>> discussion on how to execute a setup and/or teardown for a single test
>> class instead of for each test fixture on the class (see the 'setUp
>> and tearDown behavior' thread).  I have had to deal with situation
>> myself before, and I am obviously not the only one (since I did not
>> initiate the thread).  As such I'd like to propose adding a class
>> level setup and tear down method the unittest TestCase class.
>
> I think that this is the wrong approach to the problem:
>  - class scope for such fixtures drives large test classes, reduces
> flexability
I can see how this could arise, but it has not been my experience (I
have a class setup system I've been using for a little while).  A
setUp method alone can be abused to create large inflexible tests.  I
think the answer to this is good documentation that clearly states
that abusing the functionality can lead to shooting oneself in the
foot.

>  - doing it the rough way you suggest interacts in non obvious ways with
> test order randomisation
This is dependent on how randomization is implemented.  Something
simple such as pick a random test of those available shouldn't affect
the ability to keep track of whether a class's setup method hasn't
been implemented, but imitadly I'm not familiar with the internals of
any existing randomization system so I will look into these to see
what issues that would arise from this change.

>  - it also interacts with concurrent testing by having shared objects
> (classes) hold state in a way that is not introspectable by the test
> running framework.
Very true, but it seems counter intuitive to expect to be able to have
shared state in this context.
At the same time, it wouldn't be acceptable to change in a way that
breaks frameworks with such functionality.

>
> I'd much much much rather see e.g. testresources integrated into the
> core allowing fixtures to be shared across test instances in a way that
> doesn't prohibit their use with concurrent testing, doesn't make it
> awkward to do it across multiple classes. I'm happy to make any
> [reasonable] changes (including license) to testresources to make it
> includable in the stdlib if that's of interest.
A pretty good approach for a complicated setup, but in a simple case
where you only need a line or two it seems like a lot of boiler plate
to get the job done.  Though I'll look into this library a little more
as I am not intimately familiar with it at the moment.

>
> -Rob
>