[rspec-users] Fixjour and others

Scott Taylor scott at railsnewbie.com
Fri Feb 6 07:09:47 EST 2009

Juanma Cervera wrote:
> Hello
> I have seen that some people in this list is using Fixjour as the
> replacement of fixtures.
> But I can't understand why it is superior or better than other
> approaches to the subject like Machinist o FactoryGirl.
> What are the problems this library resolve?
> Can somebody explain this a little.
Excuse the rant, but I need to go to bed before I wake up in 2 hours:

I think part of it is that the other plugins all have an interface that 
sort of makes you want to throw up in your mouth.  Or at least, they do 
for me.  The only two interfaces that I've understood are 
FixtureReplacements and Fixjour, and they happen to generate the same 
methods.  I asked Pat exactly what he thought it provided over 
FixtureReplacement.  Here were his exact words:

"So my main objective with fixjour is to have the simplest 
implementation possible, with a very simple API. So it will create the 
following methods: new_[model], create_[model], and 

The interface isn't much different from FRs on a day to day basis.  FR 
provides a ton more but its internal implementation is shit and very 

I don't know anything about Machinist. 

Factory girl was written because of a misconception with 
FixtureReplacement (the author thought that it didn't allow lambdas for 
associations - which is my own fault, because the api probably sucked).  
He also thought that it that relied to heavily on random values 
(although, I have no idea on how to provide good defaults - and I don't 
think that FG has solved that issue, either).  Put the ThoughtBot 
machine in full drive, and it's not hard to get recognition (it also 
doesn't hurt to have like 30 rails developers at your company who 
probably all adopt it at the same time - that's like 1/3 of rubyconf).  
I'm not taking anything away from the plugin - it looks relatively 
clean, and I'm sure the internals are OK.

Object Daddy was developed at about the same time as FR, and as far as I 
know, also originated from this Dan Manges post:


IMHO, I don't like the idea of defining test data in the model, and I 
don't like the necessarily tight coupling of one class => one fixture.  
Usually thats a good bet, but we all have "edge" cases.  Once in a while 
an "Admin" won't be it's own class, it'll be a boolean field on the 
User.  Does this mean that I now should need to pass :admin => true for 
every test case against a user?  Couldn't I just say "create_admin" 
instead of create_user(:admin => true)?

There are a ton of subtle details to each of them (like: do they support 
attr_protected attributes, lambdas for wrapping the association when 
defining it, inheriting default fixtures, model namespacing, 
automatically merging attributes, creating custom named fixtures (for 
those times you want admin_user but don't have an Admin model), etc. 
etc.).  Creating a matrix of these things and seeing which plugins 
implement which would be interesting.

Ultimately, I guess it comes down to the API, and what feels correct and 
clean.  All of these do basically the same thing at the core, but they 
can all be abused to create terrible specs.

That's my .02 on the matter,


> Thank you.
> Juanma

More information about the rspec-users mailing list