SetUp functions for multiple test cases
gspschmid at gmail.com
Tue Jan 20 16:24:49 CET 2009
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
> 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.
More information about the Python-list