Fixjour and others

Testing RSpec
1

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.

Thank you.
Juanma

2

I’m sorry for the question.

I have just seen that this question is already treated in a very near
thread.
I didn’t see it.

Juanma

3

Juanma C. 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 M. 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

4

Well sometimes one can’t use an existing library becuase of some
reason or other, like in my case not using ActiveRecord.

So I came up with yet another way to do it, I think it is a hyvrid
between Fixtures and Factories.

outlined here…

http://blog.wolfman.com/posts/42

5

Scott T. wrote:

[
“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.”

This seems to be an anti-pattern in the Rails community:

“I can’t follow Library X, so I’ll write Library Y, which is lightweight
and
obeys YAGNI, and is the simplest possible implementation.”

I confess: I’ve done it too. But it’s nearly always the wrong approach.
If
you can’t follow Library X’s implementation, but you agree with its
philosophies, refactor it!

Competing libraries should have different goals, different purposes,
different anything other than just “cleaner code”. If Merb can refactor
itself into Rails, you can do it with fixtures, authentication, file
attachments, or what have you. As easy as Github makes forking, the
choice
of libraries should no longer be driven by “this one was updated most
recently” or “this one uses the most recent design idioms”.

As someone wrote recently: The minute you start coding, you’re writing
legacy code.

Jay L.

6

I started writing up a response about why I wrote Fixjour, and why I
want it to be its own project, but it got really long. Here’s a
Markdownified gist: Why I Wrote Fixjour.md · GitHub.

For the record, I think FR is a great tool (I link to it in Fixjour’s
README), it’s just not for me. Read the gist above and you’ll be able
to see why.

Pat

7

Pat N. wrote:

I started writing up a response about why I wrote Fixjour, and why I
want it to be its own project, but it got really long. Here’s a
Markdownified gist: Why I Wrote Fixjour.md · GitHub.

For the record, I think FR is a great tool (I link to it in Fixjour’s
README), it’s just not for me. Read the gist above and you’ll be able
to see why.

Pat

+1

Nice post, Pat. I think this post belongs somewhere on the c2 wiki.

Although, I still disagree with the create_admin example. Here’s a
rundown of the different syntaxes:

I’d prefer to have the flexibility there. In FR you could use
create_user(:admin => true) every time, which works well when that’s the
only attribute given. When extra attributes are needed as well, I think
the test can become too busy. But I do think you are on point with this
comment:

“If I did feel the need for a create_admin helper, it might be a sign
that I need an Admin model.”

I’m not opposed to named fixtures per-se, I’m opposed to named fixtures
where the intent of the spec becomes obfuscated by the attributes. So
why does user_joana_who_has_19_outstand_mortgage_payments also have an
invalid email address? Who knows. But with create_admin(:other_flag
=> true) the meaning of the spec is probably going to be clear, even if
the internal implementation isn’t. And ultimately, my idea behind a
good spec doesn’t reveal an internal implementation (black box testing
has always been more of my forte) .

I’m less gung ho about supporting attr_protected. I can see it going
both ways.

Thanks for the interesting post,

Scott

8

I think that named fixtures are primarily a matter of taste. With that
being
said, I did want to explain mine a bit.

When extra attributes are needed as well, I think the test can become too
busy.

A lot of time, I feel like processing the overrides hash is just a
bandaid
over something missing from the actual object model. Creating named
fixtures
is essentially the composition of these patches, which can lead to
obfuscating object creation methods that evolve to mask smells in the
real
code (If I sound a bit dramatic, it’s because I was recently on a
“perfect
storm” project where this happened). I know it’s not really feasible to
do
everything through extra attributes though. I just prefer defining
“scenario” methods elsewhere, that are totally detached from the
builders,
which should be as isolated as possible.

So why does user_joana_who_has_19_outstand_mortgage_payments also have an
invalid email address? Who knows.

Totally. That’s the kind of setup we were working with before deciding
to
rip it out.

I’m less gung ho about supporting attr_protected. I can see it going
both

ways.

Today I was working on a side project and the abundance of
attr_protected
fields really started to stick in my crawl, so I started toying with a
way
to make it easier to create builders that integrate these fields without
losing the fact that they are in fact special. The result is in a branch
(
http://github.com/nakajima/fixjour/tree/protected-attributes) until I
can
figure out whether I like it or not, but the gist is this:

define_builder(Person) do |klass, overrides|
  klass.protected :purchases
  klass.new :purchases => 0, :email => "[email protected]"
end

The protected fields can then be declared and passed to the creation
methods
like they were any other method, but we still get to see the fact that
they’re protected. I’d love to get some feedback on this style, as I’m a
bit
on the fence about it. Not such much because #protected means other
things
in Ruby, but because I’m not sure if it should be more explicit.

Pat

On Sun, Feb 8, 2009 at 3:44 PM, Scott T. [email protected]
wrote:

Pat

+1

Nice post, Pat. I think this post belongs somewhere on the c2 wiki.

Although, I still disagree with the create_admin example. Here’s a
rundown
of the different syntaxes:

fixtures.rb · GitHub

I’d prefer to have the flexibility there. In FR you could use
create_user(:admin => true) every time, which works well when that’s the
only attribute given. When extra attributes are needed as well, I think
the
test can become too busy. But I do think you are on point with this
comment:

“If I did feel the need for a create_admin helper, it might be a sign
that
I need an Admin model.”

I’m not opposed to named fixtures per-se, I’m opposed to named fixtures
where the intent of the spec becomes obfuscated by the attributes. So
why
does user_joana_who_has_19_outstand_mortgage_payments also have an invalid
email address? Who knows. But with create_admin(:other_flag => true)
the
meaning of the spec is probably going to be clear, even if the internal
implementation isn’t. And ultimately, my idea behind a good spec doesn’t
reveal an internal implementation (black box testing has always been more
of

reason or other, like in my case not using ActiveRecord.

different anything other than just “cleaner code”. If Merb can
refactor
rspec-users mailing list

[email protected]://
rubyforge.org/mailman/listinfo/rspec-users

rspec-users mailing list

[email protected]://
rubyforge.org/mailman/listinfo/rspec-users