Pat Nakajima 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: http://gist.github.com/60389.
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:
http://gist.github.com/60497
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
On Feb 7, 9:36 pm, Jim Morris <wolfma...@gmail.com> wrote:
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
On Feb 7, 8:16 am, Jay Levitt <lists-rs...@shopwatch.org> wrote:
Scott Taylor 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 Levitt
_______________________________________________
rspec-users mailing list
rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
