[rspec-users] Fixjour and others

Scott Taylor scott at railsnewbie.com
Sun Feb 8 15:44:07 EST 2009


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... 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...
>>
>> http://blog.wolfman.com/posts/42
>>
>> 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
>>>> 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... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>>>       
>> _______________________________________________
>> rspec-users mailing list
>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>>     
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>   



More information about the rspec-users mailing list