Have a way to detect unmatched calls

Following your advice on twitter, here is my recommendation to make Mockito as a better place.

As you probably know, I’m EasyMock lead dev. But working on many projects where I haven’t picked the mocking framework, I happen to work a lot with Mockito as well.

I’m annoyed by a bunch of little things but one problem makes me want to throw my computer by the window. They might already be a solution for it but I am not aware of it. I know you worked on the verification mode lately to do more or less that but it doesn’t work when not using @Mock and not really satisfactory.

So, let’s say I’m working on legacy code with tests using Mockito. My current example is code the worked perfectly and then I did a Mockito migration. So any() isn’t matching null anymore. So my when are not matching anymore. Mockito is returning null by default and the test is failing because of that.

The problem is that I have no clue where the when was called. This is complicated legacy code and tests are not as simple as one would like. So, here is what I can do:

1- Find usage, put a breakpoint everywhere the method is called, find which call is returning null, fix the when()

But I have 20 recordings… Takes ages to find what I’m looking for

2- Convert to Easymock. The unexpected calls will fail right away. I will fix them and be done

I will restate again: The wrongly non-matching when have been a source of annoyance with Mockito for many many years now.

[henri-tremblay]

Reading #1097, my opinion:

• unstubbed, non-void method fails immediately with “I am unstubbed!” exception

Seems ok. Not sure you need to bother yourself about void/non-void. Having void to fail can make the test more resilient to unexpected calls (assuming, the tester forgot to verify for no more interactions)

• such method is implicitly marked as verified for the verifyNoMoreInteractions() calls

Probably a good idea

• unused stubs are detected at the end of test and trigger failure

Yes. You might need to some verifyAllStubsWereUsed when not using rules or runner

• requires to use doReturn API for stubbing mocks (limitation of the syntax, already known gotcha when using test “spy” or strict stubs)

This is a problem because it is needed after the fact. So you are already in front of tons of mocks and recording and don’t want to change them. You are just looking for the stupid any() that was matching null in previous versions of Mockito. That’s why I was proposing a goStrict() that will put the mock in a strict mode. Any when() or doReturn would fail after goStrict() and so will an unexpected call.

[henri-tremblay]

I’ve continued digging. Two things are helpful:

• Mockito.mockingDetails(mock).printInvocations() will print the invocation so if you think some mock is not called as expected, you can dig into that
• Mockito.verifyZeroInteractions(mock) to make it fail and see the unexpected invocation

They are helpful but when you have a lot of mocks it requires a code change and a bit of guessing and investigating to find out what’s failing. Not a nice a the direct failure a strict mock will allow.

Due to the Mockito architecture (no replay phase), my assumption is that isn’t possible without adding something like Mockito.goStrict(mock) before the test phase.