On Tue, Mar 18, 2008 at 5:04 AM, Chris Parsons <[EMAIL PROTECTED]> wrote: > Hi David > > > On 18 Mar 2008, at 08:15, David Schmidt wrote: > > > Here is his email to me, less his signature as I don't want to make > > this personal. I'd like to see what the RSpec user community has to > > say in response to his comments, below: > > [snip email] > > For me, it basically boils down to: use whichever is appropriate for > what you're testing, as long as it provides good coverage and makes > the tests easy to write. If the tests are hard to write, and you're > mocking/stubbing all over the place, it's a smell that your > implementation is probably not loosely coupled enough - perhaps you > need to refactor. > > Mocks are a very useful testing construct, but using them religiously > everywhere is as bad as not using them religiously, IMHO. > > Have you read Mocks aren't Stubs[1]? It's a very good treatise on the > advantages and disadvantages of using mocks in testing. Pat Maddox > also wrote an article on this subject recently that I found very > helpful[2].
I agree wholeheartedly! I'd also recommend Mock Roles, Not Objects[3] When I'm spec'ing views, for example, I tend to follow this path: 1. start with an expectation, watch it fail 2. get it to pass with hard-coded values in the view 3. replace the hard-coded view code with the code I wish I had[4] 4. mock/stub whatever I need at the time in the example to get it to pass This last step varies depending on the state of the system. If the model class I want doesn't exist, I use a mock object. If it does exist, I'll use stub_model[5] to provide isolation from the db, but allow the real model code to be invoked. If I used a mock to begin with, I may switch it later. The point is that while I'm in the view I want to stay focused on the view. FWIW. Cheers, David [3] jmock.org/oopsla2004.pdf [4] Writing "the code I wish I had" is something I learned from James Grenning at Object Mentor. [5] stub_model is a new method in git - will be released with 1.1.4. It creates a real model instance and prevents database access a la unit_record (but on an instance by instance basis). This allows you to reap the benefit of isolation from the db while reducing the false positives that concern so many with using mocks in Ruby. > > Thanks > Chris > > [1] http://martinfowler.com/articles/mocksArentStubs.html > [2] > http://evang.eli.st/blog/2008/2/3/it-s-not-about-state-or-interactions-it-s-about-behavior > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
