[rspec-users] How do I best setup data for Story Runner?

[Scott Taylor]

On Sep 27, 2007, at 6:11 PM, Carl Porth wrote:

> On Sep 27, 2007, at 12:41 PM, Pat Maddox wrote:
>
>> On 9/26/07, Simon Peter Nicholls <simon at mintsource.org> wrote:
>>> Just started looking at the Story Runner integration, and am
>>> converting a few Rails integration tests to get a feel for it.
>>>
>>> My integration tests relied on fixtures, and since my models have a
>>> significant amount of validation (and hence need valid data unless I
>>> save without validation), this has made setup easy.
>>>
>>> With stories however, I'm wondering what the recommended approach  
>>> is.
>>> Mocks are out I assume, since the point is testing the stack, but  
>>> are
>>> fixtures out too? Should we be meeting our more complex or  
>>> repetitive
>>> setup needs by treating it as plain ruby code that needs refactoring
>>> via regular Ruby/OO techniques (Object Mother et al)?
>>>
>>> A typical scenario for me might involve a couple of users with
>>> different roles, plus a collection of other collaborating objects.
>>>
>>> Thanks
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>>
>>
>> I don't use fixtures (the yaml type, anyway) in story runner stories.
>> I construct objects in the given blocks.  I find that that does two
>> things for me.  First, it clearly expresses what a given really  
>> means.
>>  So when I say Given "an activated user," I don't have to go dig
>> around some YAML files.  If I need to understand it I can just  
>> look at
>> the code and see
>> u = User.create! :login => "pat"
>> u.activate
>>
>> Secondly, constructing your object graph instead of using fixtures
>> means you're actually exercising your code.  With fixtures you just
>> instantiate some objects and fill them with data, which may not
>> necessarily be valid (they require maintenance).  Also if you're  
>> using
>> stuff like before/after create hooks to create child objects, using
>> fixtures bypasses that.
>>
>> I look at fixtures as a weird kind of mock.  You're not using the  
>> full
>> implementation, so what's the point really?  I'd rather use a real
>> object or a proper mock object.  In stories I don't use mocks at all,
>> so obviously I'll go for the full implementation.
>>
>> Pat
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> +1
>
> I've adopted a factory pattern for organizing my tests inspired by:
> http://www.dcmanges.com/blog/38
>

Yeah, that post was great, and inspired me to create a plugin, which  
has been essential to my workflow.  Here is a screencast (and a  
shameless plug) for it:

http://railsnewbie.com/files/fixture_replacement_demo.mov

I was/am quite tired (it's about 3 AM), so just forward through my  
stupidity.

Regarding Pat's post: fixtures aren't a weird kind of mock, they are  
real data.  The problem is their large overhead in scaling to a  
project of any size (especially the typical one with lots of  
associations). Plus, fighting with YAML just sucks.  Am I putting in  
invalid data, or are those tabs instead of spaces?  The truth is that  
they are *PAINFUL* to use, and that's why no one uses them (and why  
"testing" sucks, and is done after a project instead of before).

  Personally, I'd love to use mocks in my model specs, but I just  
can't bring myself to do it.  It, too, is painful, because I  
essentially need to understand the details of how activerecord  
works.  Why spend an hour figuring out that  
User.find_or_create_by_username 'scott' should be stubbed out as  
User.find("username" => "scott") and not User.find(:username =>  
"scott")?  Have you read Jay Field's blog recently?  Stubbing  
ActiveRecord::Connection::Column ?  Give me a break.  That's going to  
break the second you upgrade rails.

Mocks are great for external libraries (or objects which you  
control), but with rails everything is so tightly woven together that  
mocking/stubbing seems to be more pain then it's worth.  The only  
positive thing the stub approach has going for it is the speed factor.

I'd be very interested in hearing how you are using mocks  
successfully without the overhead of learning tons of plumbing.

Scott