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
- 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
On Wed, Jan 20, 2010 at 8:37 PM, Robert Collins <robertc@robertcollins.net> wrote: think the answer to this is good documentation that clearly states that abusing the functionality can lead to shooting oneself in the foot. 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