Re: [Rails-core] Extract fixtures to a separate gem for Rails 4

[Josh Susser]

I think YAML fixtures still have value for testing. For example, I use fixture_builder to generate fixture data in Ruby and dump it to YAML files. You get the best of both worlds: define the data in Ruby (even using FactoryGirl or other test data library), and load from YAML files for fast test setup.

It might make sense to extract the fixture stuff into a gem so it can be more loosely coupled, but I'd expect resistance to removing the feature entirely.

--

Josh Susser

http://blog.hasmanythrough.com

On Thursday, July 5, 2012 at 11:48 AM, Olek Janiszewski wrote:

Hi guys,

I've noticed the trend of trimming the fat from Rails in preparation for version 4 (which I appreciate).

Do you think it'd make sense to also remove the test fixtures engine from Rails 4? From what I've seen, it's now more common to use more advanced solutions, with FactoryGirl leading the pack, and it's usually more practical to use Ruby to define fixtures, rather than YAML.

More specifically:

- would the core team approve of such effort?

- how much work would it mean?

- (related) how tightly are fixtures actually used within Rails' tests?

It's hard to me to estimate the overall value/cost ratio, but if it's high enough, I'd be willing to take a shot at it.

-- 

Bye,

Olek Janiszewski (exviva)

[Prem Sichanugrist]

I myself have been stopped using YAML fixture for a while and switched to Factory Girl. +1 to extract that to a gem.

This might be the same case as Active Resource, where when people use it less then it get removed.

- Prem

[Luís Ferreira]

I would really appreciate a ruby based fixture creation solution such as FactoryGirl to come bundled with rails instead of the YAML ones.

+1 for this feature.

On Jul 5, 2012, at 7:48 PM, Olek Janiszewski wrote:

Hi guys,

I've noticed the trend of trimming the fat from Rails in preparation for version 4 (which I appreciate).

Do you think it'd make sense to also remove the test fixtures engine from Rails 4? From what I've seen, it's now more common to use more advanced solutions, with FactoryGirl leading the pack, and it's usually more practical to use Ruby to define fixtures, rather than YAML.

More specifically:

- would the core team approve of such effort?

- how much work would it mean?

- (related) how tightly are fixtures actually used within Rails' tests?

It's hard to me to estimate the overall value/cost ratio, but if it's high enough, I'd be willing to take a shot at it.

-- 

Bye,

Olek Janiszewski (exviva)

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/MNYYrHc3b_gJ.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Cumprimentos,

Luís Ferreira

[Rafael Mendonça França]

In my experience using factories are, at least, twice slower than using fixtures. I always prefer to use fixtures.

I don't see any real gain in removing it from Rails, neither extracting it to a gem.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca

[Luís Ferreira]

Factories give a lot more functionality, including inheritance and get really fancy when combined with stuff like Faker. I don't think that the discussion here should be whether factories are useful or not, but if they are a good enough value added to rails.

I personally like the added functionality and expressability of factories and do not mind the extra time it takes to run the tests. But in my opinion what should really be taken in account is what we want someone that is just starting to test with rails to be using. Are fixtures really the best way to it? If so then maybe we could just add some reference in the documentation to other ways of doing it (factories), if not then changing the default to factories or extracting everything to separate gems and leave it to the user would be two possible solutions, IMO.

Cumprimentos,

Luís Ferreira

[Ken Collins]

Factories are not slow! 

Using a clean database and re-seeding fixtures with factories on top of a clean database and not using transactional fixtures is slow!

For the past 2 years I have been using transactional fixtures while using factories to seed that data, vs YAML files. The process is pretty simple.

1) Make Rails 'test:prepare' taks call a 'db:test:seed' task.

2) Make the 'db:test:seed' task load a file that leverages your factory gem of choice.

3) Provide methods that leverage ActiveRecord::Fixtures.identify so both factories and tests can get to seeded data.

I finally found some time a few months back to put my work int a gem called "named_seeds"

https://github.com/metaskills/named_seeds/

I would love to see Rails bless a default factory gem. Then utilize a strategy like my "named_seeds" gem. It would allow:

1) Backward compatibility to fixtures using methods like "user(:admin)".

2) A way to use any factory gem, the db/test/seeds.rb would be like db/seeds.rb, open ended.

3) Hook into calling db/seeds for lookup tables, etc before test seeding too.

4) Load other engine seeds before hand too.

All of this named_seeds does now.

 - Ken

[Rafael Mendonça França]

I think we are not talking about add factories by default in the Rails, but about extract/remove fixtures.

We have a attempt to have the best of both words, that I think that can be added in the Rails.

https://github.com/plataformatec/hermes/blob/master/lib/hermes/builders.rb#L1-79

And you are right Ken, factories are not slow, but the current implementation/usage of they are. Your solution seems solve these actual issues.

 

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca

[Steve Klabnik]

Factories and factory_girl are one of the worst things to ever happen to Rails.

I can't possibly see this ending as anything but a giant flamewar email thread.

[Ryan Bigg]

I agree with Steve. Would love to see a reasoned discussion on what you'd replace FactoryGirl with. 

p.s. My test setup is better than your test setup.

--
Ryan Bigg

On Friday, 6 July 2012 at 6:54, Steve Klabnik wrote:

Factories and factory_girl are one of the worst things to ever happen to Rails.

I can't possibly see this ending as anything but a giant flamewar email thread.

[Olek Janiszewski]

Thanks everyone for sharing your feelings about FactoryGirl, but that's not what I care about :). I consider this off-topic, please start a separate discussion about that gem.

My question is: should YAML fixtures be extracted from Rails 4?

[Ryan Bigg]

No, they should not. They are used rather extensively in the Active Record tests. 

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/BXqUsA2xD94J.

[Aaron Patterson]

On Thu, Jul 05, 2012 at 02:56:04PM -0700, Olek Janiszewski wrote:
> Thanks everyone for sharing your feelings about FactoryGirl, but that's not
> what I care about :). I consider this off-topic, please start a separate
> discussion about that gem.
>
> My question is: should YAML fixtures be extracted from Rails 4?

No.

--
Aaron Patterson
http://tenderlovemaking.com/

[Neeraj Singh]

Does anyone know of a gem which uses fixtures for testing? I looked at devise, arel etc but they do not use fixtures. Just trying to learn proper usage of fixtures.

Of course Rails itself uses fixtures a lot but I am looking for other simpler gems.

Thanks

- Neeraj

[Rodrigo Rosenfeld Rosas]

One of the reasons I prefer factories over fixtures is that my tests express better.

login_user = Factory.create :user
login_as login_user
...

In this case, someone reading this test knows that it only matters that a user is being created. It shouldn't have any special attributes.

But if I do something like this:

login_user = Factory.create :user, name: 'Rodrigo'

Then I know that the name attribute of the user is relevant for that test.

Another reason is that I only load the records needed by my tests, not lots of unrelated data that could have some side effect on the tests.

Best,
Rodrigo.

Em 05-07-2012 16:50, DHH escreveu:

I continue to use and love fixtures. I don't see them going anywhere. I've been entirely unconvinced by all the factory approaches I've seen so far.

But I'm always willing to look at good before/after code if someone wants to pitch this further.

On Thursday, July 5, 2012 1:48:45 PM UTC-5, Olek Janiszewski wrote:

Hi guys,

I've noticed the trend of trimming the fat from Rails in preparation for version 4 (which I appreciate).

Do you think it'd make sense to also remove the test fixtures engine from Rails 4? From what I've seen, it's now more common to use more advanced solutions, with FactoryGirl leading the pack, and it's usually more practical to use Ruby to define fixtures, rather than YAML.

More specifically:

- would the core team approve of such effort?

- how much work would it mean?

- (related) how tightly are fixtures actually used within Rails' tests?

It's hard to me to estimate the overall value/cost ratio, but if it's high enough, I'd be willing to take a shot at it.

[Gabriel Sobrinho]

My vote is to extract to a external gem.

It's fine if you like fixtures, but it's fine if you like factories too.

I think the benefit of release cycle decoupled from rails will be valuable.

What are the downsides?

[Xavier Noria]

On Fri, Jul 6, 2012 at 2:30 PM, Gabriel Sobrinho <gabriel....@gmail.com> wrote:

My vote is to extract to a external gem.

It's fine if you like fixtures, but it's fine if you like factories too.

Absolutely.

Rails provides a curated stack. The stack reflects the preferences of the core team, we make some choices that we believe are the best defaults. For instance, when we compare Test::Unit and RSpec code side by side we prefer Test::Unit, and that's what you get in the stack. Same for fixtures.

In addition to that, the framework also makes the design/development effort to let users be able to plug in alternatives, and Rails 3 made this less hackish than it was before. So it is totally fine that you prefer factories, and we'll make sure you can use them.

[Gabriel Sobrinho]

I see.

What about release cycle?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.

To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Cheers,

Gabriel Sobrinho

[Xavier Noria]

On Fri, Jul 6, 2012 at 6:30 PM, Gabriel Sobrinho <gabriel....@gmail.com> wrote:

I see.

What about release cycle?

Well, in the case of Rails the value of extracting something like this to a gem has more to do with the internal organization of the framework in my view.

Things in Rails follow the release cycle of Rails generally speaking. For example, Active Record is a gem, but there aren't releases of Active Record independent from Rails, albeit it can be used outside Rails.

I don't see a need to extract fixtures to a gem personally.

[Gabriel Sobrinho]

ok, thanks for explanation Xavier :)

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Cheers,

Gabriel Sobrinho