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