[rspec-users] How do I best setup data for Story Runner?
jonathan at parkerhill.com
Fri Sep 28 13:20:35 EDT 2007
Thanks for the plug-in, http://thmadb.com/public_svn/plugins/
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 :)
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
>>>> Mocks are out I assume, since the point is testing the stack, but
>>>> fixtures out too? Should we be meeting our more complex or
>>>> setup needs by treating it as plain ruby code that needs
>>>> 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.
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>> I don't use fixtures (the yaml type, anyway) in story runner
>>> I construct objects in the given blocks. I find that that does two
>>> things for me. First, it clearly expresses what a given really
>>> 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"
>>> 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
>>> 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
>>> 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
>>> so obviously I'll go for the full implementation.
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>> I've adopted a factory pattern for organizing my tests inspired by:
> 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:
> I was/am quite tired (it's about 3 AM), so just forward through my
> 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.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users