[TIP] Testing the Fixture?

[Kumar McMillan]

Hi Pete.

Re: problem #1 : "the load-the-data operation should probably get
tested."  Probably the easiest way to do this is just move this
process into it's own object and write unit/functional tests for that
object.  That is, make a data object and write test_load() and
test_unload() tests.  Then in your real test just call data.load() and
data.unload() and be done.

As for problem #2, aborting the test when your setUp() function fails,
I think this should happen naturally, no?  Or maybe you are talking
about many failing tests related to a single data loading process.
Yes, I let the failures cascade everywhere, it's more dramatic like
that.  But more seriously, nose's --stop / -x option is awesome.  And
I once experimented with a plugin that only reports unique exceptions
since sometimes the same exception can occur in hundreds of tests.  It
is here: http://code.google.com/p/nosetrim/ ... but needs some love.
It probably won't work for 0.10 and I haven't used it in a while so
perhaps it, errm, isn't all that useful.

Back to data loading and having no idea about what you're loading data
into, if it *is* a database, you may be able to use this module I
created: http://code.google.com/p/fixture/ .  It is tested :)
However, it has some quirks, mostly since it requires some kind of db
manager like sqlalchemy or sqlobject and you have to get those set up
right.  I can try to help you if you run into a specific problem.

On Nov 21, 2007 8:59 AM, Pete <pfein at pobox.com> wrote:
> Hi all-
>
> Any suggestions on how to write tests where the fixture gets tested as well?
>
> A little background:
> My library is a data storage service, so the load-the-data operation should
> probably get tested.  However, that operation is also the fixture for
> subsequent tests, which retrieve/search/delete/etc..
>
> 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.
>
> 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?
>
> Sorry if this makes no sense. Oh, I'm using nose btw.
>
> --
> Peter Fein   ||   773-575-0694   ||   pfein at pobox.com
> http://www.pobox.com/~pfein/   ||   PGP: 0xCCF6AE6B
> irc: pfein at freenode.net   ||   jabber: peter.fein at gmail.com
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>