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.
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.