On Wed, Jun 10, 2009 at 6:55 AM, Amit Kulkarni<li...@ruby-forum.com> wrote: > > In the book it is mention about mock and stub objects.but i am > still not getting the reason behind it.
The Very Short Answer: You don't want your controller specs failing because your model is broken. Your _model_ specs should fail instead. You also don't want your controller specs running slow because it's hitting a database. (That, again, is the model's problem.) The answer to this is not to talk to the model in your controller specs. Your specs talk only to the controller. For everything else, you create one or more fake model-like thingies that give all the right answers when asked the right questions. Then, when your controller specs fail, you know where to focus your energy. In the controller. (That, or they fail because the specs or the mocks and stubs are slightly wrong. In my experience that's more common, and that's one reason why I hardly ever do controller specs any more. But still: there you go. That's the reason for the way it's done canonically.) -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users