feature request: super-strict mode

[cvmocanu]

Fist, thanks for creating a very nice mocking tool.

Now to the issue :)

Background

Mockito doesn't really make a distinction between mocks and stubs.
This is currently a problem, because we can't create a good mock.
Let me explain.

Stubs should always be lenient. If they are not, then the test is overly coupled with a particular implementation, and instead of helping you when you refactor, you also need to fix tests. Fixing tests is not really acceptable if only implementation details changed, but the outcome is exactly the same.
In any case, this can currently be accomplished in Mockito using lenient stubs (or hand-written stubs, if there are invariants that need to be maintained - e.g. after List.add(), List.size() should return +1; in this case, using Mockito to mock a List would be more pain than gain (of course you shouldn't mock a list anyway, it's just an example to explain invariants)).

Moving on to mocks. Currently Mockito returns defaults for all methods, even if there is no explicit expected call.
This leads to really fragile tests (passing by accident), because some production code reacts differently to nulls vs non-nulls.
This makes it's easy to write tests that no one understands why they pass (since returning null is implicit, rather than explicit).
In addition, it makes it very difficult to determine what calls have not been properly stubbed. I recently had this situation, and it's really nasty to debug.

The feature request

Introduce a mode (e.g. configuration option, a different strictMock creation method, don't forget about the JUnit support annotations, etc.) where defaults are never returned. Instead, an exception will be thrown that the call has no matching expectation. Basically, whenever you would normally return a default (e.g. null) because of a missing or unmatched expectation, Mockito should throw an exception instead.

This will make it very easy to fix "accidental" tests - those test that are passing by mistake, because the default value just happened to be what the test wants.