On Aug 27, 2010, at 10:52 PM, Justin Ko wrote: > > > On Aug 27, 8:18 pm, Myron Marston <myron.mars...@gmail.com> wrote: >> One of the primary dangers of using mocks is that your unit tests may >> be testing against an interface that is different from that of your >> production objects. You may simply have misspelled the method (e.g. >> object.should_receive(:methd_name) rather than method_name), or you >> may have changed the interface of your production object without >> updating your tests. >> >> Obviously, you should have some integration coverage that will catch >> these kinds of errors (and I do), but it's nice when they're caught by >> your unit tests since they're so much faster than integration tests. >> I've been using a pattern to help with this for a while: >> >> it "safely mocks a method" do >> object.should respond_to(:foo) >> object.should_receive(:foo).and_return(:bar) >> object.do_something_that_calls_foo >> end >> >> Basically, I add a respond_to? check before mocking or stubbing a >> concrete object (obviously, I don't do this for a pure mock object). >> If/when I rename the mocked method, I'll get a test failure. I think >> it'd be nice to add this to rspec-mocks itself. A few additional >> thoughts about this potential feature: >> >> * This would only apply when you're mocking/stubbing concrete objects; >> on a pure mock or stub it wouldn't do the check. >> * Should this print a warning or raise an error so the test fails? >> * Should it be configurable? I could see some people not wanting this >> feature, particularly if you're strictly following the outside-in BDD >> process where the specs on the outer layers (say, a controller in a >> rails app) mock methods that have not yet been defined on the inner >> layers (say, a model in a rails app). >> * This feature could potentially take things a step further and when >> you specify mock arguments using `with`, it could check the arity of >> the method and be sure that the method accepts that number of >> arguments. >> >> What do people think about this idea? >> >> Myron >> _______________________________________________ >> rspec-users mailing list >> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > I'm confused on why you need to use respond_to. The purpose of a stub > is to change the behavior of an object. Therefore, if the behavior is > *not* being changed, your specs should fail. If the spec does not > fail, then the stub was worthless in the first place.
Not necessarily. In the case of a stub on a real object, the purpose is to control the environment in which the example runs. Consider a method on an object that returns one value before noon and a different value at noon and after. In an example for another object that depends on the time-dependent object, we might stub that method to respond as though it were before noon in one example, and after noon in another. This means that when you run this spec in the morning, the example that stubs morning-like behaviour is not changing anything or needing to fail. Same for the other example in the afternoon. Cheers, David _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
