Machinist VS Factorygirl - Pros and Cons

Machinist vs FactoryGirl - pros and cons

Machinist was actually heavily inspired by factory_girl, but varied because machinist's author wanted a different syntax. Since then, factory_girl added different syntax layers to simulate other factory libraries (including machinist's "blueprint" syntax). In other words, both are extremely similar, just with a different default syntax. Personally, I use factory_girl.

Factory_girl or machinist?

No. Those libraries are not stubbing/mocking libraries*.

Both Machinist and Factory Girl are libraries that help you instantiate objects in your tests without the fuss of fixtures. After you've instantiated an object using one of these libraries, you might then mock or stub methods on that object, but Factory Girl and Machinist wouldn't have anything to do with that.

Check out Mocha for stubbing/mocking.

*Factory Girl has a stubbing feature that's specifically for stubbing models, but nothing for general stubbing/mocking.

Test data generation for Ember.js (like factory_girl or machinist)

I created a project called Ember Data Factory Guy recently to help create fixture data for ember projects that use ember-data.
It works with REST or ActiveModel adapter and has test helpers to make using it pretty easy.

Check it out here:

https://github.com/danielspaniel/ember-data-factory-guy

It supports belongsTo, hasMany ( even polymorphic ) associations .. sequences, embedded belongsTo .. and a few other things.

Testing dynamic initial states with FactoryGirl and StateMachine

You may be able to just add an after_build callback on your factory:

Factory.define :car do |c|
  c.after_build { |car| car.initialize_state }
end

However, I don't think you should rely on setting your initial state in this way. It is very common to use ActiveRecord objects like FactoryGirl does (i.e. by calling c = Car.net; c.my_column = 123).

I suggest you allow your initial state to be nil. Then use an active record callback to set the state to to the desired value.

class Car < ActiveRecord::Base
  attr_accessor :stolen # This would be an ActiveRecord attribute

  state_machine do
    state :parked, :moving
  end

  before_validation :set_initial_state, :on => :create

  validates :state, :presence => true

  private
  def set_initial_state
    self.state ||= stolen ? :moving : :parked
  end
end

I think this will give you more predictable results.

One caveat is that working with unsaved Car objects will be difficult because the state won't be set yet.

---

Related Topics