Hello,
I had seen many controller spec using mock and stub objects.
I had written controller spec earlier without these objects.
In the book it is mention about mock and stub objects.but i am
still not getting the reason behind it.
Can somebody tell me what are these and why are we using it
especially in controllers?
--
Posted via http://www.ruby-forum.com/.
On Wed, Jun 10, 2009 at 5:55 AM, Amit Kulkarni<lists at ruby-forum.com> wrote:> Hello, > > ? ? ?I had seen many controller spec using mock and stub objects. > > ? ? ?I had written controller spec earlier without these objects. > > ? ? ?In the book it is mention about mock and stub objects.but i am > still not getting the reason behind it.Did you read the chapter on Mock Objects?> > ? ? ?Can somebody tell me what are these and why are we using it > especially in controllers?
On Wed, Jun 10, 2009 at 6:55 AM, Amit Kulkarni<lists at 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 (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org
David Chelimsky wrote:> On Wed, Jun 10, 2009 at 5:55 AM, Amit Kulkarni<lists at ruby-forum.com> > wrote: >> Hello, >> >> ? ? ?I had seen many controller spec using mock and stub objects. >> >> ? ? ?I had written controller spec earlier without these objects. >> >> ? ? ?In the book it is mention about mock and stub objects.but i am >> still not getting the reason behind it. > > Did you read the chapter on Mock Objects?Yes i have read Mock Objects. I understood a bit that Mock object create objects virtually so that we can run our specs.It helps us in that we dont have to actually create those objects. But i am still not getting my hand on it. we may have a situation that just for instance that all the development is done and we are now writing the spec for it.In this case all the coding in controller,model are done. So when we write specs for controller do we have to create mock objects? What if we write specs in controller without using mock objects?Will it be fine? Also since i am using the beta version Mocking Objects part is not there.And it is does not give clearcut idea from the topic Mock Objects. Also it will be very helpful if you can provide me a link or anything which can give me details of Mocks and Stubs.How to use it?When to use it..e.t.c Thanks & Regards, Amit -- Posted via http://www.ruby-forum.com/.
On 11 Jun 2009, at 08:17, Amit Kulkarni wrote:> David Chelimsky wrote: >> On Wed, Jun 10, 2009 at 5:55 AM, Amit Kulkarni<lists at ruby-forum.com> >> wrote: >>> Hello, >>> >>> ? ? ?I had seen many controller spec using mock and stub >>> objects. >>> >>> ? ? ?I had written controller spec earlier without these >>> objects. >>> >>> ? ? ?In the book it is mention about mock and stub >>> objects.but i am >>> still not getting the reason behind it. >> >> Did you read the chapter on Mock Objects? > > Yes i have read Mock Objects. > I understood a bit that Mock object create objects virtually so that > we > can run our specs.It helps us in that we dont have to actually create > those objects. > > But i am still not getting my hand on it. > > we may have a situation that just for instance that all the > development > is done and we are now writing the spec for it.In this case all the > coding in controller,model are done. > So when we write specs for controller do we have to create mock > objects? > What if we write specs in controller without using mock objects?Will > it > be fine?If you''re writing the specs after you''ve written the code, you''re losing a lot of the value of mock objects. Mock objects were originally devised as a design tool for use when doing TDD. TDD stands for Test *Driven* Development, meaning that you write the test before you have written any of the code. When you''re doing this, you want to be able to build the system piece by piece, class by class, so you write tests for a single object at a time, and use mock objects to assemble quick, lightweight sketches of the surrounding objects that you imagine it will interact with when the system is finished.> Also since i am using the beta version Mocking Objects part is not > there.And it is does not give clearcut idea from the topic Mock > Objects. > Also it will be very helpful if you can provide me a link or anything > which can give me details of Mocks and Stubs.How to use it?When to use > it..e.t.cThis is a big topic which is not going to be easy to explain over email. Here is some more stuff for you to read. http://www.patmaddox.com/blog/you-probably-dont-get-mocks http://www.mockobjects.com/book/ http://www.jmock.org/oopsla2004.pdf http://www.martinfowler.com/articles/mocksArentStubs.html Matt Wynne http://beta.songkick.com http://blog.mattwynne.net
Matt Wynne wrote:> On 11 Jun 2009, at 08:17, Amit Kulkarni wrote: > >>>> >> those objects. >> it >> be fine? > > If you''re writing the specs after you''ve written the code, you''re > losing a lot of the value of mock objects.Actually i am writing specs before the code is written.I saw many examples especially in controllers they are using mocks.So i was bit confused regarding the same. Also Imagine the same situation where code is written and we are writing specs for that then is it necessary to use mocks?If Yes why since code is already written?> Mock objects were originally devised as a design tool for use when > doing TDD. TDD stands for Test *Driven* Development, meaning that you > write the test before you have written any of the code. When you''re > doing this, you want to be able to build the system piece by piece, > class by class, so you write tests for a single object at a time, and > use mock objects to assemble quick, lightweight sketches of the > surrounding objects that you imagine it will interact with when the > system is finished. > >> Also since i am using the beta version Mocking Objects part is not >> there.And it is does not give clearcut idea from the topic Mock >> Objects. >> Also it will be very helpful if you can provide me a link or anything >> which can give me details of Mocks and Stubs.How to use it?When to use >> it..e.t.c > > This is a big topic which is not going to be easy to explain over > email. Here is some more stuff for you to read. > > http://www.patmaddox.com/blog/you-probably-dont-get-mocks > http://www.mockobjects.com/book/ > http://www.jmock.org/oopsla2004.pdf > http://www.martinfowler.com/articles/mocksArentStubs.htmlThanks a lot Matt for the above links. -- Posted via http://www.ruby-forum.com/.
On Thu, Jun 11, 2009 at 4:39 AM, Amit Kulkarni<lists at ruby-forum.com> wrote:> Matt Wynne wrote: >> On 11 Jun 2009, at 08:17, Amit Kulkarni wrote: >> >>>>> >>> those objects. >>> it >>> be fine? >> >> If you''re writing the specs after you''ve written the code, you''re >> losing a lot of the value of mock objects. > > Actually i am writing specs before the code is written.I saw many > examples especially in controllers they are using mocks.So i was bit > confused regarding the same. > > Also Imagine the same situation where code is written and we are writing > specs for that then is it necessary to use mocks?If Yes why since code > is already written?It''s not a matter of necessity, but rather a matter of costs and benefits. This is a very complex and subtle topic, which is one reason a lot of people who avoid mocking do so. At some level, it is simpler to not use any mocks or stubs anywhere. But if you choose that path, there are a lot of benefits you''re missing out on. Steve wrote in his reply earlier in this thread that we don''t want out controller specs failing because the model is broken. But it''s not just when the model breaks. It''s when the model *changes*. Say, for example, that we''ve got a Widget model that has a required name attribute, and an optional date attribute. We''ve got this in our controller spec: describe WidgetsController do describe "POST create" do context "with valid attributes" do it "redirects to the widget list" do post :create, :widget => {:name => ''Foo''} response.should redirect_to(widgets_path) end end context "with invalid attributes" do it "re-renders the ''new'' template" do post :create, :widget => {} #missing the required name response.should render_template(''new'') end end end end Now imagine that we''re working on the model spec and we get a new requirement that the date is required. So we write a spec: describe Widget do it "requires a date attribute" do Widget.new(:name => ''Foo'', :date => nil).should_not be_valid end end That fails, so we add "validates_presence_of :date" to the model and then the spec passes. Success! Except now the valid attributes case in the controller spec fails because we''ve changed the meaning of valid for this model. So you have to go back and change this and every other example that creates a Widget without a date. Now stubs/mocks are certainly not the only way to fix this problem. You can use fixtures, centralized helper methods, object mothers, and test data builders. These are all tools that help you centralize the creation of objects, so when you do run into this sort of problem, you only need to fix it in one place. But you still need to fix it once, which takes your focus away from the task at hand. And you don''t get the speed savings you get w/ stubs/mocks. And you still get controller specs failing when models are broken. For the record, I generally use stubs/mocks in controller specs, but I tend towards test data builders in model specs. But I''m also very comfortable with all of these tools and am perfectly willing to use test data builders in controller specs or mocks/stubs in model specs when that is the better choice for a given situation. Really, I think that''s what we should all be striving for. Not so much "should I use mocks or not," but "when should I choose to use them?" HTH, David>> Mock objects were originally devised as a design tool for use when >> doing TDD. TDD stands for Test *Driven* Development, meaning that you >> write the test before you have written any of the code. When you''re >> doing this, you want to be able to build the system piece by piece, >> class by class, so you write tests for a single object at a time, and >> use mock objects to assemble quick, lightweight sketches of the >> surrounding objects that you imagine it will interact with when the >> system is finished. >> >>> Also since i am using the beta version Mocking Objects part is not >>> there.And it is does not give clearcut idea from the topic Mock >>> Objects. >>> Also it will be very helpful if you can provide me a link or anything >>> which can give me details of Mocks and Stubs.How to use it?When to use >>> it..e.t.c >> >> This is a big topic which is not going to be easy to explain over >> email. Here is some more stuff for you to read. >> >> http://www.patmaddox.com/blog/you-probably-dont-get-mocks >> http://www.mockobjects.com/book/ >> http://www.jmock.org/oopsla2004.pdf >> http://www.martinfowler.com/articles/mocksArentStubs.html > > Thanks a lot Matt for the above links. > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
(NOTE: This reply is no longer really for Amit''s benefit any more. What David said made perfect sense as an answer to the original question. Now I''m just spinning off into theory.) ((But David -- if the repetition of this whole argument On Thu, Jun 11, 2009 at 9:36 AM, David Chelimsky<dchelimsky at gmail.com> wrote:> > Steve wrote in his reply earlier in this thread that we don''t want out > controller specs failing because the model is broken. But it''s not > just when the model breaks. It''s when the model *changes*.True. Though if I wanted to play Devil''s Advocate, I could make a case that from the point of view of the controller, it''s the same thing. "What? The Widget wants WHAT now? Hey, I know all about widgets, and this widget''s not doing what I expect any more. Must be something wrong with it." (Of course, that exact attitude points to a lot of what''s wrong in human relationships, not just OO ones. >8-> So I wouldn''t defend that case rigorously. Still -- it''s a problem that can be exacerbated by the sort of static expectation mocks play into.)> That fails, so we add "validates_presence_of :date" to the model and > then the spec passes. Success! Except now the valid attributes case in > the controller spec fails because we''ve changed the meaning of valid > for this model. So you have to go back and change this and every other > example that creates a Widget without a date.Yep. But isn''t the difference just a matter of timing? If you just added a new requirement to Widgets, the controller *needs* to change before you hit production or it''s going to break in real-world use. You''ll eventually have to go back and change every mock, and _then_ change every example anyway. If you don''t, then the mocks no longer represent the true expectation of a Widget and your controller''s behavior is no longer correct from the widget''s POV. You end up with specs that pass when the application wouldn''t. As a matter of practicality, I think I would *prefer* the controller spec to fail right away so that I don''t forget to update my mocks later on. Yes, I *should* have integration tests that would catch this, so I ought to be safe if I''m doing other things right; but if the controller spec will have to change sooner or later, I''d rather it bugged me to change it sooner. As I see it, the cost of violating DRY and repeating the expectations of a Widget in a number of mocks, which then have to be maintained separately, is *usually* higher than the cost of referring to the actual model, with slower test runs and less specific failure pinpointing. I don''t see earlier spec repair as a cost at all, given that those specs will have to change anyway. There may be cases where this would pay off to me, but the typical highly coupled Rails model/controller relationship isn''t it. In practice I only use mocks these days to take the place of outside interfaces or bigger, more conceptually distinct subapplications.> [ . . . ] Really, I think > that''s what we should all be striving for. Not so much "should I use > mocks or not," but "when should I choose to use them?"And here... Here you made me really pause and think. Enough to make it a separate message. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org
On Thu, Jun 11, 2009 at 11:36 AM, Stephen Eley<sfeley at gmail.com> wrote:> (NOTE: This reply is no longer really for Amit''s benefit any more. > What David said made perfect sense as an answer to the original > question. ?Now I''m just spinning off into theory.) > > ((But David -- if the repetition of this whole argument > > On Thu, Jun 11, 2009 at 9:36 AM, David Chelimsky<dchelimsky at gmail.com> wrote: >> >> Steve wrote in his reply earlier in this thread that we don''t want out >> controller specs failing because the model is broken. But it''s not >> just when the model breaks. It''s when the model *changes*. > > True. ?Though if I wanted to play Devil''s Advocate, I could make a > case that from the point of view of the controller, it''s the same > thing. ?"What? ?The Widget wants WHAT now? ?Hey, I know all about > widgets, and this widget''s not doing what I expect any more. ?Must be > something wrong with it." > > (Of course, that exact attitude points to a lot of what''s wrong in > human relationships, not just OO ones. ?>8-> ?So I wouldn''t defend > that case rigorously. ?Still -- it''s a problem that can be exacerbated > by the sort of static expectation mocks play into.) > > >> That fails, so we add "validates_presence_of :date" to the model and >> then the spec passes. Success! Except now the valid attributes case in >> the controller spec fails because we''ve changed the meaning of valid >> for this model. So you have to go back and change this and every other >> example that creates a Widget without a date. > > Yep. ?But isn''t the difference just a matter of timing? ?If you just > added a new requirement to Widgets, the controller *needs* to change > before you hit production or it''s going to break in real-world use.This may be true in some cases, but generally with validations the controller passes the params straight through to the model without caring about them in any way. In those cases, where the controller is only interacting with methods that are part of AR::Base, you''re not really risking a validation change effecting the controller''s behaviour.> You''ll eventually have to go back and change every mock, and _then_ > change every example anyway. ?If you don''t, then the mocks no longer > represent the true expectation of a Widget and your controller''s > behavior is no longer correct from the widget''s POV. ?You end up with > specs that pass when the application wouldn''t.I think you''re generalizing here, which is what I was driving at with my point about knowing when to use stubs/mocks and when not to. As I mentioned above, these changes need not always propagate up to the controller or its specs. I would agree with you that there is additional risk in cases where the changes to the model actually do require changes to the controller. Though I mitigate that risk by working with Cucumber first, which catches those sorts of mis-alignments a bit later than if I wasn''t using stubs/mocks, but certainly before those changes make it to production. At the moment, one of my projects does not use Cucumber. We''re using RSpec for both higher level and lower level specs. In this case, the level of use of stubs/mocks is far lower than in other projects I''ve worked on.> As a matter of practicality, I think I would *prefer* the controller > spec to fail right away so that I don''t forget to update my mocks > later on. ?Yes, I *should* have integration tests that would catch > this, so I ought to be safe if I''m doing other things right; but if > the controller spec will have to change sooner or later, I''d rather it > bugged me to change it sooner.I can appreciate that, though it''s not how I operate.> As I see it, the cost of violating DRY and repeating the expectations > of a Widget in a number of mocks, which then have to be maintained > separately, is *usually* higher than the cost of referring to the > actual model, with slower test runs and less specific failure > pinpointing.I run the specs after every change (using autospec). For this to work effectively, the specs need to run fast. This is one of the benefits, in my view, of having two separate tools for dealing at different views of the code (i.e. RSpec and Cucumber).> ?I don''t see earlier spec repair as a cost at all, given > that those specs will have to change anyway. ?There may be cases where > this would pay off to me, but the typical highly coupled Rails > model/controller relationship isn''t it. ?In practice I only use mocks > these days to take the place of outside interfaces or bigger, more > conceptually distinct subapplications. > > >> [ . . . ] ? Really, I think >> that''s what we should all be striving for. Not so much "should I use >> mocks or not," but "when should I choose to use them?" > > And here... ?Here you made me really pause and think. > > Enough to make it a separate message.Looking forward to it. Cheers, David> > > > -- > Have Fun, > ? Steve Eley (sfeley at gmail.com) > ? ESCAPE POD - The Science Fiction Podcast Magazine > ? http://www.escapepod.org > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Thu, Jun 11, 2009 at 12:56 PM, David Chelimsky<dchelimsky at gmail.com> wrote:> > This may be true in some cases, but generally with validations the > controller passes the params straight through to the model without > caring about them in any way. In those cases, where the controller is > only interacting with methods that are part of AR::Base, you''re not > really risking a validation change effecting the controller''s > behaviour.This is a good point. I think I got a little too zoomed in on the example. (In which that wasn''t entirely clear, as it did focus on specific attributes being passed.) I stand corrected, thank you.> I run the specs after every change (using autospec). For this to work > effectively, the specs need to run fast. This is one of the benefits, > in my view, of having two separate tools for dealing at different > views of the code (i.e. RSpec and Cucumber).And it''s why the active side project I really *am* spending time on right now is a smarter, more human-efficient replacement for Autospec. >8-> But enough of that until I can actually show something for it. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org
Even if we are using mocks and if our models are changed then also we need to change our spec. Same for if we don''t use mocks. So same question i am asking Are mocks really useful? Also When to use if at all we want to use? I searched on net regarding the same but till now no success :-) Also i had started writing controller specs without using mocks just to see how it works?Will it be ok? -- Posted via http://www.ruby-forum.com/.
On Fri, Jun 12, 2009 at 4:46 AM, Amit Kulkarni<lists at ruby-forum.com> wrote:> Even if we are using mocks and if our models are changed then also we > need to change our spec. > Same for if we don''t use mocks.This is true in some cases, but not in many of the common cases. Here''s an example: describe WidgetsController do describe "POST create" do context "with valid attributes" do WidgetsController.stub(create!).and_return(true) post :create response.should redirect_to(widgets_path) end context "with invalid attributes" do WidgetsController.stub(create!).and_raise(ActiveRecord::RecordInvalid(mock_model(Widget))) post :create response.should render_template(''new'') end end end These two examples will never have to change due to a change in model validation rules. The only reason they''d ever have to change would be if you wanted to make a change the controller itself and how it handles the create() action. In this case we''re using stubs, not mocks, but they are serving the purpose of isolating change.> So same question i am asking Are mocks really useful? > Also When to use if at all we want to use? > I searched on net regarding the same but till now no success :-)Amit - you don''t have to search the net. Steve, Matt and I have all taken valuable time to try to explain this to you, and Matt even posted some very useful links for you. From this thread, the RSpec book, and those links, you''ve got enough information in front of you to start answering these questions for yourself. Please take some time to read some of this stuff. If you have any specific questions about any of that reading material, please feel free to ask them. Cheers, David> > Also i had started writing controller specs without using mocks just to > see how it works?Will it be ok?You''ll be fine if you don''t use mocks. I''d be fine if I didn''t use mocks. I happen to know how and when to use them so I like to use them. Cheers, David> -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >