[TIP] Testing the Fixture?
kumar.mcmillan at gmail.com
Wed Nov 21 16:39:09 PST 2007
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
More information about the testing-in-python