SetUp functions for multiple test cases

Roy Smith roy at panix.com
Tue Jan 20 09:57:51 EST 2009


In article 
<45b0bf56-673c-40cd-a27a-62f9943d9f1a at r41g2000prr.googlegroups.com>,
 Georg Schmid <gspschmid at gmail.com> wrote:

> I've just started working with unittests and already hit a snag. I
> couldn't find out how to implement a setup function, that is executed
> only _once_ before all of the tests. Specifically, I need this for
> testing my database interface, and naturally I don't want to create a
> new database in-memory and fill it with example data for every single
> test case.

Short answer -- there's no way to do it in the unittest framework.

The True Unit Test Zealots will argue that all tests should be 100% 
independent of each other, which means there should be NO common state 
between test cases.  For that matter, they will also argue that unit tests 
should not interface with external resources like databases.  And they're 
right.

On the other hand, the Real World Test Pragmatists will argue that this is 
just not practical in all cases.  Real programs have classes which interact 
with the outside world, and they need to get tested.  You could stub out 
the external resource, but that's a lot of work, and may introduce as many 
problems as it solves.  Sometimes, a big part of what you're testing is 
your understanding of the external world (i.e. "does this really work like 
it's documented?").

Plus, some operations are just too expensive to do for every test case.  I 
don't know how long it takes to build your in-memory database.  If it takes 
one second, it probably makes sense to do it for every test case (unless 
you've got thousands of test cases).  If it takes 10 minutes, then it makes 
sense to do it once and deal with the fact that you're violating True Unit 
Test Dogma.

Anyway, do what I do.  I run the tests with a:

if __name__ == "__main__":
   blah blah

block at the bottom of the test file.  Just do your "do once" setup in that 
code block and store the result in a global.

You might have your setUp() method re-assign the global to an instance 
variable and then your test cases can access it via self.whatever.  The 
reason for that is if at some point in the future you change your mind and 
decide to re-build the database in setUp() for each test, you just have to 
change setUp(), not touch the individual test cases.



More information about the Python-list mailing list