If you use Mockito to make a fake Logger and verify that ‘log’ was called, then you’ve made a mock, not a stub.

My reason is somewhere between keeping Mockito not very aggressive and pushing tests to be smarter. Smarter, meaning failing for the ‘right’ reasons. Example: if the functionality is missing, then the failure should somehow point out that… the functionality is missing (e.g. central assertion fails). If the functionality is missing I guess I don’t want a failure like: ‘you didn’t stub me correctly’. I’d prefer: ‘this assertion fails because functionality is missing. By the way: this stub was called with wrong arguments.’

Unless I’m wrong :) Anyway, if you use Mockito 1.8.0 check out VerboseMockitoJUnitRunner

When can such an error occur?
1) functionality is missing: in that case I would like to see, you stubbed a method but it is not called yet
2) you wrongly stubbed something: in that case I want to see the error too
3) you stubbed something, but it is not needed: an error too please

I might have overlooked something, but I think it is handy if the test would fail on stub configuration errors.

1) invoking a deleteBiggest…() twice instead of once
=> return was correct: deleted obj, but due to a wrong if-block, delete was called again

I’m not too worried about this one. I’m putting it in a separate test method that verifies that the biggest is deleted. It’s an interesting behavior and I’m happy to create a specific method that describes it.

2) getting the parameter sequence wrong (creating a 1-way relationsship between 2 obj the wrong way)
=> return of the relation was mixed, so data base and program state did not match anymore

verify seems paranoid / senseless when testing good code, but I prefer writing 1 more verify to reading 10 lines of ugly code.

I agree that if you make a mistake in calling a stubbed method (e.g. wrong args) it’s not going to be immediately visible what’s wrong and some extra debugging might help. I respect you prefer to have a verify() that helps out in this matter. However, there is a feature I’d like to introduce in Mockito that will try to solve this problem. Hear me out let me know what you think :)

I’d like Mockito to provide extra debugging info only when the test fails. Exception message could potentially contain information like: you stubbed this method this way but you called it with different arguments. Or: you stubbed this method but this stub was not really used at all. The interesting part is that I’d like this extra debugging info to be added to any exception, regardless if it’s NullPointerException from the code or AssertionError from the test. Basically, any exception/error that makes the test fail.

I guess if Mockito had this, you wouldn’t need to look for too long at 10 lines of ugly code, neither you would need to verify your stubs, right?

In many cases, assert() on the retrun value will fail, if the method call (of the dao) is wrong, but imho a failed verify is more expressive then a failed assert.

examples:
1) invoking a deleteBiggest…() twice instead of once
=> return was correct: deleted obj, but due to a wrong if-block, delete was called again
2) getting the parameter sequence wrong (creating a 1-way relationsship between 2 obj the wrong way)
=> return of the relation was mixed, so data base and program state did not match anymore

1) no chance in hell finding that w/o verify() or some code coverage tool
2) a more rigrid stub may have uncovered this as well

I know especially 2) is more like additional debugging, but if you need to look into someone else’s code / test it, every little bit helps.

verify seems paranoid / senseless when testing good code, but I prefer writing 1 more verify to reading 10 lines of ugly code.

I prefer Mockito

Great!

Mockito docs say: “Although it is possible to verify a stubbed invocation, usually it’s just redundant”. If you have ideas how to make javadocs clearer don’t hesitate to write to our mailing list.