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

Zach Moazeni zach.lists at gmail.com
Tue Nov 13 09:50:06 EST 2007

+1 on David's response.


On Nov 13, 2007, at 9:44 AM, David Chelimsky wrote:

> On Nov 13, 2007 7:18 AM, James Mead <jamesmead44 at gmail.com> wrote:
>> Mocha [1] used to only allow you to mock *existing* methods on  
>> *concrete*
>> classes. This functionality accidentally got removed a while ago,  
>> but I'd
>> like to reintroduce it asap.
> I beg of you, please don't. At least not as a default behaviour.
> Mocks are very powerful tools for interface discovery
> (http://www.jmock.org/oopsla2004.pdf). With an enforcement rule like
> the one you propose reinstating, we'd have to stop working on the
> object at hand to go write a class and/or method. This would break the
> flow of the current task, force us to shift focus.
> Not only do we break the current flow, but by going over to the other
> object and sticking in a stub to get the mock to shut up, we run a far
> greater risk of leaving things 1/2 done than we do by sending
> unsupported messages and have our integration tests expose those
> holes.
> For anybody who is serious about doing TDD, this would be a major step
> backwards.
> What we've talked about adding to ... ahem ... another mocking
> library, is the ability engage this behaviour explicitly with an
> environment variable or a command line switch. That would provide the
> best of both worlds because you could stay focused on the task at hand
> AND you could get a report of the methods you don't have on
> collaborating classes so you know where to go next.
> I'd strongly recommend that you consider a similar path before simply
> forcing this rule on mocha users.
> Cheers,
> David
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer

More information about the mocha-developer mailing list