SetUp functions for multiple test cases

[Georg Schmid]

On Jan 20, 3:57 pm, Roy Smith <r... at panix.com> wrote:
> In article
> <45b0bf56-673c-40cd-a27a-62f9943d9... at r41g2000prr.googlegroups.com>,
>  Georg Schmid <gspsch... 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.

Thanks, exactly what I needed to know.