On Nov 13, 2007 7:18 AM, James Mead <jamesmead44 / 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