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 :) On Wed, Aug 6, 2014 at 5:20 PM, Chad Woolley <[email protected]> wrote: > This list is for rails core discussion, so this question is probably > better suited for rubyonrails-talk. > > But I'll answer anyway (it would be great to get something like > fixture_builder into Rails someday, none of the alternatives are good IMO): > > I use factories + fixtures via https://github.com/rdy/fixture_builder > > 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. > > -- Chad > > > On Wed, Aug 6, 2014 at 5:16 AM, Pruss Wan <[email protected]> wrote: > >> Hi, >> >> 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. >> >> >> Thanks >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- At. Carlos Antonio -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
