Refactoring fixtures/testcase configurability

All,

I've been hacking on-and-off for a while on an extensive refactoring
of AR's fixture support. I'm reworking the test/unit integration right
now, and I've run into a case where I'd like to hear some opinions.

Assuming that the following list of stuff is configurable, which items
do you think should be able to be changed on a testcase-by-testcase
basis?

fixture_path # the directory where the fixture files live
fixture_loaders # the loaders: YAML, CSV, etc
fixture_filters # the features: all the current foxy fixtures stuff, etc.
fixture_persister # how does this stuff get in to the DB?

It seems obvious to me that being able to change the fixture path
per-testcase is important, but I'm not sure about the others. What do
you think?

~ j.

Assuming that the following list of stuff is configurable, which items
do you think should be able to be changed on a testcase-by-testcase
basis?

fixture_path # the directory where the fixture files live
fixture_loaders # the loaders: YAML, CSV, etc
fixture_filters # the features: all the current foxy fixtures stuff, etc.
fixture_persister # how does this stuff get in to the DB?

It seems obvious to me that being able to change the fixture path
per-testcase is important, but I'm not sure about the others. What do
you think?

I can't think of a particularly urgent need to change anything other
than fixture path on a class-by-class basis.

I agree.

jeremy

If you're jumping in on fixtures, can you take a look at supporting fixture_scenarios in your changes? If you need help with that, let me know - I'm motivated to make sure they keep working. From what I've seen in the fixture_scenarios code, it only cares about fixture_path out of those four items you listed.