Earlier versions of Mocha used not to allow you to stub a non-existent
method. I'm intending to re-introduce this with a manual override.
May I recommend that the default behaviour is that these are ignored,
but that you can explicitly tell mocha to fail or warn you of
expectations for methods that don't exist?
Also there is an experimental feature in Mocha called responds_like or
which constrains a mock to only allow methods that exist on a
specified object or class.
However, in the end there's no substitute for acceptance tests that
exercise critical business functionality.
It's important to understand that mocking as we approach it today
comes from TDD as part of an XP process, which divides tests into
Customer Tests and Programmer Tests (note: the lingo has morphed over
time, but the distinction has not). The idea is that you begin with
customer defined end-to-end tests (that fail miserably at first) and
use those to steer you in the right direction in terms of what objects
to develop. Then you drive the development of those objects with more
In this environment, mocking allows us to keep the programmer tests
focused on small bits of functionality. This makes it much easier to:
- develop code when the other pieces it relies on don't exist yet
- understand failures
- run the tests fast
The cost is the scenario Alex described: programmer tests all pass,
but a customer test fails. This is a GOOD THING. This is why we have
different levels of testing. If every level of testing exercises
everything in its entire environment, then we really only have one
level of testing, and we lose the unique benefits we intent to reap
from having different levels of testing.
Conversely, if you are not doing any high level testing in addition to
the object-level testing, then you probably shouldn't be using mocks