[mocha-developer] how to ensure signature compliance while mocking in ruby

[James Mead]

On 26/11/2007, Pradeep Gatram <pradeep.gatram at gmail.com> 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