From: James Mead Date: 2008-01-03T01:03:19+09:00 Subject: Re: how to ensure signature compliance while mocking in ruby On 26/11/2007, Pradeep Gatram wrote: > Sorry for vanishing for a couple of weeks. I have been using ur > suggested approach of 'responds_like'. Although its a good start, it > still does not give me complete confidence. All it tells me is whether > the method is present or not. It does not guarantee signature > compliance. For e.g., referring back to my example... > > class Bar > def method2 param1 > end > end > > The above implementation of method2 in Bar will cause FooTest to pass > even with responds_like. But the 2 parameter signature is clearly not > supported. > > I agree, an integration test should and will catch this scenario and > will fail. But its not possible to write integration tests for every > scenario. After all, the expected method call could happen under a > convoluted condition. A classic case where, I believe, the unit tests > should be able to give me complete guarantee of the state of code. I don't think you have to write an integration test for *every* scenario. I would aim to write just enough to give decent coverage of the integration points between classes, probably focussing on common or important business scenarios. > So there does appear to be a need for stricter checking. Leaving the > default behaviour as is, maybe introduce a new method like > mocked_object.strictly_expects(:blah)... I have considered something along these lines. I'll give it some more thought. I've added a feature request on rubyforge [1]. > That leads me to another aspect? How about validating the return types > :D. Java/C# again gave me that additional safety net of knowing that the > return types were correct while I was mocking (at least thats what I > remember). Hmm. I'm not sure how you are suggesting this could be achieved. Ruby methods do not declare their return type in the method declaration. I think the best way of obtaining the safety net you describe is to use integration tests. Alternatively you could go back to a statically typed language ;-) -- James. http://blog.floehopper.org http://tumble.floehopper.org [1] http://rubyforge.org/tracker/index.php?func=detail&aid=16769&group_id=1917&atid=7480