RFC: Additional functionality for PyUnit

[MikeK]

Well, my post generated a big yawn, but since I just now ran into a
situation that's a good example of why I would like PyUnit to be
enhanced a bit, I thought I'd share it.

But first, my original post, redux...

mkent at atlantic.net (MikeK) wrote in message news:<efd753ca.0108180619.111f10d1 at posting.google.com>...
> Here's a proposed change to unittest.py that I'd like your comments
> on.
> 
> I've found unit testing with PyUnit to be invaluable.  I've gotten to
> the point where writing any Python code without unit tests seems,
> well, perverse.  :)  But there's an inadequacy in PyUnit I keep
> running into that I'd like addressed.
> 
> I often work with code that requires a large amount of work to set up
> a test for, and the setup code takes an appreciable amount of time to
> run.  Often, several tests that are grouped into a test case all
> require a common setup.  Now, PyUnit provides us with setUp() and
> tearDown() methods that we can define for each test case, which is
> good.  The setup() method is run prior to EACH test method of a test
> case, and the tearDown() method is run after EACH test method of a
> test case.  However, when you have several test methods defined in a
> test case, that all need a common setup for the tests, and the setup
> is both work and time intensive, what you really want is to have a
> different and additional set of setup and teardown code that is only
> run ONCE for the test case.
> 
> This would let me run the difficult and long-running setup for a
> series of related tests once.  It would really make unit testing my
> code more doable.


Here's my further example.  I have some code I need to unit test that
basically does a create, append, and modify to some data in a file.

Test Case:

Step 1: create the directory to run the test in.  This is a
global setup step.

Step 2: Test the create code.  Step 1 must have been run.

Step 3: Test the append code.  Steps 1 and 2 must have been run.

Step 4: Test the modify code.  Steps 1 and 2 must have been run.

Step 5: Delete the test directory.  This is a global teardown step.


Step 1 creates the directory that is needed by all of the subsequent
steps.  Step 2 creates a file which is then needed by Steps 3 and 4,
which means that I can't delete the test directory for each test,
unless I want to have to run Steps 1 and 2 as part of the setup for
Steps 3 and 4.

Now, in this example, Steps1 and 2 are simple, cheap, and quick to
run.  But just imagine a situation where Step 1 was 'create an SQL
database with all tables, columns, and relationships', and Step 2 was
'write multimegabytes of setup data to the database'.

So, what I really want is for Steps 1 and 5 to be done 'globally',
that is, I need to create a setup state that persists across all of
the individual tests contained in the test case, then tear down that
setup only when all of the dependent tests have been done.

If PyUnit were to be extended to add a 'globalSetUp' method, run once
before all other test methods in the test case, and a
'globalTearDown', run once after all other test methods in the test
case,
that are in addition to the currently-supported 'setUp' and 'tearDown'
methods, I'd be very happy.

Or am I missing something that would already give me what I want?