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

Jonathan Linowes jonathan at parkerhill.com
Fri Sep 28 13:20:35 EDT 2007


Scott,
Thanks for the plug-in, http://thmadb.com/public_svn/plugins/ 
fixture_replacement
I've started using it, replacing my ad hoc factory methods
And I like the idea of putting the factory in db/

btw, for the record, while the Dan Manges blog was posted Aug 07, the  
first time I saw this technique is as a protected create_user method  
in the acts_as_authenticated plugin test/user_test.rb (although not  
to replace fixtures but to test against them :)

Regards
linoj


On Sep 28, 2007, at 3:48 AM, Scott Taylor wrote:

>
> 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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users



More information about the rspec-users mailing list