[TIP] Testing the Fixture?

[Robert Collins]

On Wed, 2007-11-21 at 12:41 -0800, iain duncan wrote:
> On Wed, 2007-21-11 at 11:59 -0800, Titus Brown wrote:
> > -> 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
> > test.
> > 
> > for example,
> > 
> > class Test:
> >    def setup(self):
> >       assert 0
> > 
> >    def test_1(self):
> >       pass
> > 
> >    def test_2(self):
> >       pass
> > 
> >    def teardown(self):
> >       pass
> > 
> > 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.
> 
> Could you manually throw an exception that aborts all the remaining
> tests? Would there a point to that?

The key is to call
    result.stop()

The problem is that the test methods individually don't have access to
the result object. In other projects I often subclass TestCase to tweak
__call__/run to allow calling result.stop().

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.idyll.org/pipermail/testing-in-python/attachments/20071122/6a1cd8eb/attachment.pgp