[lmm]

Mockito makes it a lot worse by not having strict mocks be first-class. EasyMock is much more usable in this regard - you're usually going to have to mock every called method anyway, so it's much better to have the framework tell you when an unmocked method is called than have it silently return null and leave you guessing.

[uw_rob]

I believe Mockito can verify for you that unmocked stubs haven't been called. [0]

For people looking for an alternative take on why it is good practice to let mocked objects have default stubs for unmocked methods, see this article [1]. This article is referenced in the mocktio documentation.

[0] http://site.mockito.org/mockito/docs/current/org/mockito/Moc...

[1] https://monkeyisland.pl/2008/07/12/should-i-worry-about-the-...

[david-given]

In my experience, Mockito never actually gets to that point, because my program has called an unmocked stub, tried to use the return result, and NPEd in an obscure and hard-to-debug manner before verification call.

[uw_rob]

In my experience with Mockito and unit tests I haven't ever ran into this. However it seems like a very valid concern, and I could definitely see it causing problems.

I wonder if it is possible to use reflection and have mockito throw an exception if a stub method is called.

[lmm]

Not really. You can set a custom default answer and you can write a method that creates mocks with that answer, but there are enough rough edges that it ends up amounting to writing your own test framework. Much easier to just use EasyMock.

[lmm]

> I believe Mockito can verify for you that unmocked stubs haven't been called. [0]

As the other reply says, that doesn't help because it never gets that far.

To my mind the article you link has the wrong premise, because I do make my data tests that way - I assert that the data is exactly what I expected. Surprise changes to data would be bad, as would surprise changes to state.