freepascal / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

new verification mode: only(). For example: verify(dataAcceptor, only()).set(some good stuff); #105

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I really like that Mockito defaults to a non-strict verification, but there are 
times when you really 
know that you what to verify that only a single method has been called on your 
mock. And it can 
become cumbersome to verify(foo, times(0)).bar() over and over again, or even 
worse:

verify(foo, times(0)).bar1();
verify(foo, times(0)).bar2();
verify(foo, times(0)).bar3();
verify(foo, times(0)).bar4();
etc.
verify(foo).bar13948();

So it would be great to have a Strict.verify similar to the InOrder.verify

Thanks,

Zach

Original issue reported on code.google.com by zd...@yahoo.com on 16 Jul 2009 at 5:16

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
>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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by szcze...@gmail.com on 19 Jul 2009 at 9:02

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by szcze...@gmail.com on 11 Nov 2009 at 1:33

GoogleCodeExporter commented 9 years ago

Original comment by szcze...@gmail.com on 11 Nov 2009 at 2:51