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 <[EMAIL PROTECTED]> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
