Is there anybody out there who is really using fixtures exclusively? And if so, how do you deal with scenarios when there is a need for multiple fixture sets? (datasets that are mutually exclusive) Or is that the part where the more popular factories come in?
For those who are wondering why I even bother, I am in a situation where I have plenty of real data to test and debug with, and if these could be extracted to fixtures which are maintainable, there might be some value in this approach for integration tests.
As for “mutually exclusive” datasets, depending on your app, maybe they can co-exist in the same fixture set. E.g., have them be separate “accounts” or “projects”.
If not, you can pass flags into fixture_builder to tell it which “set” of fixtures to build.
We have been using fixtures lately in some projects at Plataformatec and it’s been work great.
The ability to have a pre-defined set of fixtures and modify them for each test works very well for most of our scenarios, and when it does not or it gets a little complex we build helpers to generate the scenario we need (generally by modifying existing fixtures, or generating new records based off the current fixtures attributes). Plus being able to use transactions most of the time is really good.
One of the most common problem I’ve seen with fixtures is that people keep growing and growing them by adding new records every time a new scenario appears - and I think that’s somewhat related to the factores background, where adding a new “trait” was just easy and didn’t impact the world. In case of fixtures it’s generally better imo to modify your set rather than adding new records, so that you can have a small and very controlled world all the time, and work with it.
Anyway, as Chad said this question is more suited for the talk mailing list, so I’d recommend you posting there
