Closed GoogleCodeExporter closed 9 years ago
Have you tried verifyZeroInteractions() / verifyNoMoreInteractions()? Please
look at
the documentation and let us know if you need something else.
Original comment by bbankow...@gmail.com
on 16 Jul 2009 at 6:45
I didn't see verifyNoMoreInteractions(), I don't know that I would have even
thought to check under the
"finding redundant invocations" section.
It would solve the my immediate problem, but maybe from a philosophical
perspective there are times when I
really want to have a real mock vs a the test spy that mockito gives me.
Maybe I just need to think about it for a little bit, but semantically saying:
Strict strict = Strict.verify(mock...)
strict.verify(foo).bar();
feels like it gets across a different meaning than:
verify(foo).bar();
verifyNoMoreInteractions();
but I guess that's just my 2 cents.
thanks for pointing me in the direction of verifyNoMoreInteractions()
Original comment by zd...@yahoo.com
on 16 Jul 2009 at 7:11
hmmm... then we probably have to change the title in this documentation
section. Any
suggestions?
Classic mock:
expect(foo).bar();
//exercise
verify(foo);
Spy:
//exercie
verify(foo).bar();
verifyNoMoreInteractions(foo);
Thanks for sharing your thoughts. I prefer spies for various reasons but it
might be
the matter of personal preference (I guess).
Original comment by szcze...@gmail.com
on 16 Jul 2009 at 8:09
maybe the title could be something like:
"'Strict verification'"
oh... also, googling "mockito strict verification" or "mockito strict"
returns the Mockito Vs EasyMock page
http://code.google.com/p/mockito/wiki/MockitoVSEasyMock
it might be nice to add something in there about using
verifyNoMoreInteractions();
so... I prefer spies like 90% of the time, but I guess in the code I'm working
with right now mocks seem like
the proper approach. I agree with the mockito approach (that's why I use it
:)) but it would be great to have a
first class mechanism in mockito to show that you're using a mock vs a spy or a
'strict mock' verse a 'nice
mock'.
no problem if we don't see eye to eye, just a suggestion. And maybe the
verifyNoMoreInteraction() is enough
to show that you're using a mock.
Original comment by zd...@yahoo.com
on 16 Jul 2009 at 8:29
oh right, good point. I'll try to update the docs accordingly. The only thing I
worry
is that devs with EM background can misinterpret 'strict' as in EM it means
something
different...
>so... I prefer spies like 90% of the time, but I guess in the code I'm working
with
right now mocks
What kind of code it is?
Original comment by szcze...@gmail.com
on 17 Jul 2009 at 4:42
>What kind of code is it?
the following is an over simplified example, so feel free to poke holes in it
but know that I'm simplifying.
I have a class that is parsing a data file
Parser.parse(dataAcceptor);
DataAcceptor has set(some data) and thereWasAProblem(THE PROBLEM)
here are two of my tests
test_parsing_informs_data_acceptor_of_a_problem() {
DataAcceptor dataAcceptor = mock(DataAcceptor.class);
new Parser(somebad data).parse(dataAcceptor);
verify(dataAcceptor).thereWasAProblem(THE PROBLEM);
verifyNoMoreInteractions();
}
test_parsing_informs_data_acceptor_sets_data_on_the_acceptor() {
DataAcceptor dataAcceptor = mock(DataAcceptor.class);
new Parser(somegood data).parse(dataAcceptor);
verify(dataAcceptor).set(some good stuff);
verifyNoMoreInteractions();
}
I find that with this type of interaction a mock is really the right testing
abstraction. That's where I think
instead something like the following might be nicer:
test_parsing_informs_data_acceptor_of_a_problem() {
DataAcceptor dataAcceptor = mock(DataAcceptor.class);
new Parser(somebad data).parse(dataAcceptor);
Strictly.verify(dataAcceptor).thereWasAProblem(THE PROBLEM);
}
test_parsing_informs_data_acceptor_sets_data_on_the_acceptor() {
DataAcceptor dataAcceptor = mock(DataAcceptor.class);
new Parser(somegood data).parse(dataAcceptor);
Strictly.verify(dataAcceptor).set(some good stuff);
}
Original comment by zd...@yahoo.com
on 17 Jul 2009 at 4:54
I think I know what you mean. This sort of thing might be implementable within
current api:
verify(dataAcceptor, only()).set(some good stuff);
try it =)
I personally use verifyNoMoreInteractions() extremely rarely
Original comment by szcze...@gmail.com
on 17 Jul 2009 at 7:00
so... I don't see the only() verification method in the docs for 1.7 or 1.8
Original comment by zd...@yahoo.com
on 17 Jul 2009 at 7:44
sorry I was a bit unclear.
There is no only() method yet - you might want to write it =)
Original comment by szcze...@gmail.com
on 17 Jul 2009 at 7:49
Original comment by szcze...@gmail.com
on 19 Jul 2009 at 9:02
Fix is in trunk. Let me know if you have any comments.
Original comment by bbankow...@gmail.com
on 27 Aug 2009 at 11:09
Original comment by szcze...@gmail.com
on 11 Nov 2009 at 1:33
Original comment by szcze...@gmail.com
on 11 Nov 2009 at 2:51
Original issue reported on code.google.com by
zd...@yahoo.com
on 16 Jul 2009 at 5:16