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
valid_[model]_attributes."
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
un-hackable.
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:
http://www.dcmanges.com/blog/38
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,
Scott
Thank you.
Juanma
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
