Verify All Option?

[Chris Gardner]

I really like mockito. I'm also a big fan of EasyMock. There are
times when I would like to verify all interactions a la EasyMock. Is
there a shorthand way to do this without having to duplicate all the
method calls in the verification stage?

[szczepiq]

>I really like mockito.

Thank you!

>I would like to verify all interactions a la EasyMock.

I'm not sure if I understand. What do you mean by "verifying all interactions"?

When I use mockito, I write small, targeted test methods to verify only the interactions I want to test.

Sometimes, I want to verify that certain interaction did not happen - then I use: verify(mock, never()).foo() . It's explicit and makes the test communicates an intent very well.

Very rarely I want to make sure that no interactions happened, then I use: verifyZeroInteractions(mockOne, mockTwo, ...) or verifyNoMoreInteractions(mockOne, mockTwo ... ). The latter can be used after you verified your mock(s) - to detect redundant invocations.

Hope that helps. Let me know if you have any questions.

Cheers,
Szczepan Faber

[Chris Gardner]

What I'm asking is is there or could there be a mode to verify all
interactions as an option as opposed to explicitly verifying
individual interactions.

On Feb 28, 2:51 pm, szczepiq <szcze...@gmail.com> wrote:
> >I really like mockito.
>
> Thank you!
>
> >I would like to verify all interactions a la EasyMock.
>
> I'm not sure if I understand. What do you mean by "verifying all
> interactions"?
>
> When I use mockito, I write small, targeted test methods to verify only the
> interactions I want to test.
>
> Sometimes, I want to verify that certain interaction did not happen - then I
> use: verify(mock, never()).foo() . It's explicit and makes the test
> communicates an intent very well.
>
> Very rarely I want to make sure that no interactions happened, then I use:
> verifyZeroInteractions(mockOne, mockTwo, ...) or
> verifyNoMoreInteractions(mockOne, mockTwo ... ). The latter can be used
> after you verified your mock(s) - to detect redundant invocations.
>
> Hope that helps. Let me know if you have any questions.
>
> Cheers,
> Szczepan Faber
>

> On Thu, Feb 28, 2008 at 6:48 PM, Chris Gardner <chris.r.gard...@gmail.com>

[Chris Gardner]

I starting to get the mockito approach now. I've been in the EasyMock
world for so long. In EasyMock, verification is paramount. From your
javadoc example and other documentation, however, I read that in
mockito verification may not even be necessary.

What I was curious about was the situation where you truly wanted to
verify ALL interactions. Could mockito work like EasyMock by a single
verify() of all stub() calls, instead of having to duplicate each stub
call in a verify() call? To use one of your examples:

//Let's import Mockito statically so that code looks clearer
import static org.mockito.Mockito.*;

//mock creation
List mockedList = mock(List.class);

//using mock object
mockedList.add("one");
mockedList.clear();

// verification a la EasyMock to verify both add and clear were
called,
// but this doesn't appear to work in mockito
// verify(mockedList);

// mockito verification
verify(mockedList).add("one");
verify(mockedList).clear();

[Igor Czechowski]

Hi Chris,

In Mockito verification is explicit. So you basically verify(assert)
if a particular invocations has already taken place or not and it's up
to you to choose what's important to be examined.
Mockito has also much stronger separation between stubbing and mocking
functionality. Thus, it let you stub some calls to make the code pass
the path you intended without verifying the calls have happened.
Moreover, you are not obligated to sub invocations unless you are
happy with default values Mockito provides you.

Such an approach separates test setup logic from test verification one
much better increasing readability.

Indeed, it may happen you end up witch more lines of code when you
have interest to verify all interaction and you have a need to stub
some invocations at the same time.

Having said that with regards to verifying all interactions at once.
Mockito wouldn't know what to verify, since you have not expressed
your intent. All may mean not what you may want.

Cheers
Igor

[szczepiq]

Few words about why mockito doesn't promote verifying stubbed methods.

1. Simplification. Back in the old days, when mock frameworks were widely unknown we've been hand-writing our stubs. But I don't remember a single case where we wanted to verify that the stub was actually called. The reason was simple: stubbed methods are implicitly verified: by the fact that stubbed value is essential in processing.

2. I saw tests where not having separation of stubbing and 'expecting' was actually harmful. The developer added return-value expectation because mock screamed with UnexpectedOperation. But he did not check if the value returned by mock was actually used... Simplifying stubbing puts accent on something more interesting: if stubbed value is used correctly.

There are rare cases when I want to verify stubbed method - I can do it in Mockito by doing ordinary verifiy(). It's explicit that's why I like it :)

So far, there is no verifyStubbedMethods() feature. Would you really miss that feature in the light of my arguments? Tell us what's your opinion!

Cheers,
Szczepan Faber

Tell us what you think. Are you really that interested in verifying stubbed methods?