[rspec-users] Fixjour and others
patnakajima at gmail.com
Sun Feb 8 18:08:40 EST 2009
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
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
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.new :purchases => 0, :email => "foo at blah.com"
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.
On Sun, Feb 8, 2009 at 3:44 PM, Scott Taylor <scott at railsnewbie.com> wrote:
> 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.
> 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
> 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
> test can become too busy. But I do think you are on point with this
> "If I did feel the need for a create_admin helper, it might be a sign
> 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
> does user_joana_who_has_19_outstand_mortgage_payments also have an invalid
> email address? Who knows. But with create_admin(:other_flag => true)
> 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
> my forte) .
> I'm less gung ho about supporting attr_protected. I can see it going both
> Thanks for the interesting post,
>> On Feb 7, 9:36 pm, Jim Morris <wolfma... at 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...
>>> On Feb 7, 8:16 am, Jay Levitt <lists-rs... at 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
>>>> 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
>>>> different anything other than just "cleaner code". If Merb can
>>>> itself into Rails, you can do it with fixtures, authentication, file
>>>> attachments, or what have you. As easy as Github makes forking, the
>>>> 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
>>>> legacy code.
>>>> Jay Levitt
>>>> rspec-users mailing list
>>>> rspec-us... at rubyforge.orghttp://
>>> rspec-users mailing list
>>> rspec-us... at rubyforge.orghttp://
>> rspec-users mailing list
>> rspec-users at rubyforge.org
> rspec-users mailing list
> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users