[TIP] Testing the Fixture?

Titus Brown titus at caltech.edu
Wed Nov 21 11:59:14 PST 2007

-> Any suggestions on how to write tests where the fixture gets tested as well?

[ ... ]
-> I've got 2 problems:
-> Structuring the tests w/o code duplication is difficult, because I don't want 
-> to run the fixture for test_load().  I can probably work around this by 
-> abstracting the guts of the fixture/test_load() into a do_load() method on a 
-> base class and then using 2 subclasses, but eww.

I don't understand the guts of your problem, but my uneducated guess
is that some variant of class or module fixtures will solve your
problem if you only want fixtures run once.

-> The second problem is that I'd like the subsequent tests to be run only if the 
-> test for the fixture passes, since they're dependent on successfully loading 
-> the data to begin with.  I dunno what the theory/best practice for this sort 
-> of contingent test is... do you just let the dependent tests fail and clutter 
-> up the screen with the same traceback half a dozen times?

This is easier to solve, I think.  If the fixture "fails" (with an
assert) I believe that the tests are not run.  However, the fixtures are
run according to the normal rules, so if you have multiple tests then
you will get multiple errors on object fixtures -- that is, one for each

for example,

class Test:
   def setup(self):
      assert 0

   def test_1(self):

   def test_2(self):

   def teardown(self):

will give you two errors, once for each time 'setup()' is run.

If you have a class or module fixture, then it will be run only once and
if it fails the tests will not be run.


More information about the testing-in-python mailing list