Re: Fabrication v. FactoryGirl

[Paul Elliott]

Hey Culley,

Fabrication does some things differently from FactoryGirl. Most
notably FactoryGirl has a really cool concept around traits and
different syntax strategies to make the syntax look like some of the
other libraries out there. Fabrication has explicit support for
Mongoid, AR, Sequel, and DataMapper whereas FactoryGirl doesn't try to
work around the differences in the libraries. Fabrication also has
support for regular Ruby objects and will let you specify init
parameters to pass to "new", which you can't do with FactoryGirl. It
also has its own transforms that you can use in the bundled cucumber
steps, which are pretty powerful. We use Fabrication on all our
projects at Hashrocket so I can tell you that it is definitely a
stable library. The 2.0 branch of Fabrication has the lazy generation
of associations removed and is focusing more on performance and
improving the orm interactions. That release should be coming out in
the next few weeks, so don't get too comfy with that feature if you
decide to go that way.

If you do decide to use Fabrication, feel free to email me anytime if
you have issues. I usually respond pretty quickly to questions and
issues.

--Paul


On May 7, 2:07 pm, Culley Smith <culley.sm...@gmail.com> wrote:
> Hey all,
>
> Anyone here using Fabrication instead of FactoryGirl?
>
> I am considering a switch, because I've been running into some issues and I
> think it might be related to FactoryGirl associations.  Fabrication allows
> for "lazy" associations.  But, before I start migrating my tests to
> Fabrication, I wanted to query the group and see whether folks out there
> were happ(y/ier) with Fabrication v. FactoryGirl.
>
> Thanks,
> Culley

[dana tassler]

We were also having issues managing associations with FactoryGirl and so in the meantime I'm just using fixtures. I know I should be using mocks, doubles, stubs and the like but as I'm working with legacy code I like to force myself to understand the code base more.

And fixtures certainly enforce understanding. >.<

On Mon, May 7, 2012 at 1:07 PM, Culley Smith <culley...@gmail.com> wrote:

Hey all,

Anyone here using Fabrication instead of FactoryGirl?

I am considering a switch, because I've been running into some issues and I think it might be related to FactoryGirl associations.  Fabrication allows for "lazy" associations.  But, before I start migrating my tests to Fabrication, I wanted to query the group and see whether folks out there were happ(y/ier) with Fabrication v. FactoryGirl.

Thanks,
Culley

--
You received this message because you are subscribed to the Google Groups "Mad Railers, the Madison, WI Ruby on Rails Users Group" group.
To visit the Madison Rails Home page, go to http://madisonrails.com/
To post to this group, send email to Mad-R...@googlegroups.com
To unsubscribe from this group, send email to Mad-Railers...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Mad-Railers?hl=en

--

"One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies."

- C.A.R. Hoare, in talking about designing software.

[Jon Kinney]

One thing I do when testing with FactoryGirl (or any other fixture replacement tool) is to avoid adding relationships in the factories themselves as much as possible. I break the rule a bit for things like roles on users but that's because I have a factory for each type of user like "admin_user" factory, "investor_user" factory, etc.

By making it a convention to avoid the association at the factory level it forces you to provide better context in your tests because you have to wire the factories together yourself. This happens either at the top of the file using the lazy "let" syntax, or in a before_each with instance vars. While it may seem like more work initially, it makes it easier to customize things about the association for specific tests and you don't have to flip back and fourth all the time to see how your have things wired together in the factory file directly. I've also ended up catching bugs on the associations that I might have missed if they were obfuscated to the factories file.

--

Jon Kinney

CTO | Bolstr.com

jon.k...@bolstr.com

920.349.7829

[Mark McEahern]

Do you use DatabaseCleaner?

// m

On Tue, May 8, 2012 at 9:04 AM, Culley Smith <culley...@gmail.com> wrote:
> Cool.  So, I'm close to having completely migrated my factories to
> Fabrication.  Taking Jon's suggestion, I'm establishing most of my
> associations in before blocks inside my specs.  That looked a bit messy at
> first, but it is saving on some headaches and I'm sure I'll find a way to
> dry things up in time.
>
> I should point out the problem I was having was unrelated to FactoryGirl, it
> had to do with my test database itself.  I had moved the test database from
> SQLite to Postgresql.  There must be something weird with my Postgresql set
> up.  On one machine, all my tests pass.  On another, almost all of them
> fail... but only when I run the entire test suite.  Individual specs pass
> just fine.  I'm guessing things aren't being cleaned up/created neatly
> between tests.  Until I track down a solution, I'm sticking with SQLite.
>
> Anyhow, I appreciate the suggestions/comments.
> Thanks,
> Culley

[dana tassler]

Funny you mention this, I've been seeing the same thing. Individual tests will pass but they'll fail when I run the entire test library.

On Tue, May 8, 2012 at 9:17 AM, Culley Smith <culley...@gmail.com> wrote:

Yeah, I'm using this setup, which is pretty much boiler plate.

  # Rspec configuration
  RSpec.configure do |config|
    config.use_transactional_fixtures = false

    # Database Cleaner configuration
    config.before(:suite) do
      DatabaseCleaner.strategy = :transaction
      DatabaseCleaner.clean_with(:truncation)
    end
   
    config.before(:each) do
      DatabaseCleaner.start
    end

    config.after(:each) do
      DatabaseCleaner.clean
    end
  end

[Mark McEahern]

I generally prefer the truncation strategy. Hulk smash, as they say.

If you have complex data seeding requirements that your tests depend
on, that may not be feasible.

Cheers,

// m

On Tue, May 8, 2012 at 9:17 AM, Culley Smith <culley...@gmail.com> wrote:
> Yeah, I'm using this setup, which is pretty much boiler plate.
>
>   # Rspec configuration
>   RSpec.configure do |config|
>     config.use_transactional_fixtures = false
>
>     # Database Cleaner configuration
>     config.before(:suite) do
>       DatabaseCleaner.strategy = :transaction
>       DatabaseCleaner.clean_with(:truncation)
>     end
>
>     config.before(:each) do
>       DatabaseCleaner.start
>     end
>
>     config.after(:each) do
>       DatabaseCleaner.clean
>     end
>   end
>
> On Tue, May 8, 2012 at 9:10 AM, Mark McEahern <mark.m...@gmail.com>
> wrote:
>>

[Jon Kinney]

I've seen the sporadic failing issue too, but usually running "rake db:test:prepare" fixes it up. If you have to run that too frequently though then something in your suite could be leaving your test db in a dirty state and it'll have to be tracked down (not a fun or fast process unfortunately).

I use and contribute to a little gem called lazy_developer which is good for several things (migrating between database types using YAML as an intermediary for one) but it also has a feature that will run rake db:test:prepare anytime that you migrate your development db so that your test db stays in sync with any migrations that you're adding. The version on github is a little bit stale... the maintainer, Brian, is working on gemafying it (there's a gem branch out there) and we should have that pushed soon. In the mean time always remember to keep your test database up to date manually with the aforementioned rake task.

Jon Kinney

CTO | Bolstr.com

jon.k...@bolstr.com

920.349.7829

[Eric Christopherson]

Interesting that this Stack Overflow thread just came up:
http://stackoverflow.com/q/10507540/1364726

Perhaps someone who knows about Fabrication can fill them in on the details.