atMost verification mode doesn't work with verifyNoMoreInteractions or InOrder

[GoogleCodeExporter]

The atMost verification "mode",

   e.g. verify( mock, atMost( n ) )

works differently than the other invocation counting modes, such as
times() and atLeast(). The others mark matched invocations as
"verified" (internal flag), but atMost does not. As a result, a call
to verifyNoMoreInteractions afterwards always fails (unless the method
wasn't called at all).

Nothing in the docs seems to indicate that atMost should behave
differently -- it's listed right alongside the other verification
modes (section 4 of the Mockito class Javadocs), and looking at the
code, it looks a little like atMost maybe just hasn't been brought up-
to-date with the way the others work.

Rewriting AtMost using the AtLeast mode class, and similarly using
AtLeastXNumberOfInvocationsChecker to make an AtMostX... class, I was able
to quickly get the behavior I expected, *and* get InOrder support to boot!
(atMost is currently not support being used in InOrder verifications.)

The attached test demonstrates both of these related issues, and all the
tests pass with my version.

Original issue reported on code.google.com by mhack...@kanayo.com on 20 Apr 2009 at 4:12

Attachments:

• DemoAtMostBug.java

[GoogleCodeExporter]

Fixed in trunk.

Thanks for reporting!

Original comment by szcze...@gmail.com on 20 Apr 2009 at 7:34

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 9 Jun 2009 at 3:15

• Added labels: Milestone-Release1.8

[GoogleCodeExporter]

I just tried 1.8.0-rc2 and atMost still doesn't work with InOrder. The AtMost 
class
would have to implement the VerificationInOrderMode interface, AtLeast does. The
attached version (based on the AtLeast classes) does work. Perhaps you can
incorporate these or just use them to get my meaning.

Original comment by at...@chebucto.ns.ca on 21 Jun 2009 at 6:25

Attachments:

• atMostInOrderFix.tgz

[GoogleCodeExporter]

Ok, well spotted. I didn't initially implement atMost() to work with inOrder 
because
there are is some trickiness around it. Have a look:

foo()
foo()
bar()
foo()

//scenario a
inOrder.verify(atMost(2), mock).foo();  //1
inOrder.verify(mock).bar();   //2

//scenario b
inOrder.verify(atMost(3), mock).foo();   //3

#1 and #3 contradict themselves but OTOH scenarios a & b are both correct... 
How do
you tackle this?

Original comment by szcze...@gmail.com on 21 Jun 2009 at 7:10

[GoogleCodeExporter]

I'm afraid I don't follow. I agree, both scenarios should pass. Where is the
contradiction? Any time the method being verified is called x or fewer times 
before
some other particular method is called (or the test ends), the verification 
succeeds,
no? What am I missing?

Original comment by at...@chebucto.ns.ca on 21 Jun 2009 at 8:42

[GoogleCodeExporter]

The problem is that when you finish evaluating //1 and //3 mockito doesn't know
whether to fail or not because it depends on further verifications. This makes 
it
very hard to implement. Does it makes more sense now?

Original comment by szcze...@gmail.com on 22 Jun 2009 at 9:24

[GoogleCodeExporter]

Please excuse my thickness, but I'm still not sure I understand your exact 
point.
However, I did come up with a situation similar to the above that passed with my
version when it should not have, so I can see there are complications.

I looked through my uses of atMost and see that they are all of the form 
atMost(1),
so I guess what I really want is a way to allow for optional method calls (e.g. 
if a
particular method is called, it must be called before something else; or allow a
particular method to be called but no others). I think I can probably eliminate 
these
if it's not easy to implement, but at the cost of making the tests a little more
brittle (because there are some potential changes to the implementation that I 
don't
care about in these particular tests).

Perhaps we should take this to the list for suggestions, unless you think 
something
like an "optionally()" verification mode might be useful and easier to 
implement.

Original comment by mhack...@kanayo.com on 24 Jun 2009 at 3:56

[GoogleCodeExporter]

>Please excuse my thickness, but I'm still not sure I understand your exact 
point.

No worries. The point is that it is very difficult to implement it because at 
the
point of verification you don't know exactly if it should pass or not.

>Perhaps we should take this to the list for suggestions, unless you think 
something
>like an "optionally()" verification mode might be useful and easier to 
implement.

How should optionally() work?

Original comment by szcze...@gmail.com on 24 Jun 2009 at 4:15

[GoogleCodeExporter]

Just to close this off...

I haven't had much time to look at trying to implement optionally(). The 
simplest
solution seemed to be to replace the stubs with fakes and check various state
variables set in the fake. The tests actually come out a little simpler, and 
this
eliminates the need to clutter up Mockito unnecessarily. If I find a better use 
case
for this, maybe I'll try again to find a working implementation.

Original comment by at...@chebucto.ns.ca on 11 Jul 2009 at 5:14

[GoogleCodeExporter]

Oh right, I'm closing this one.

Original comment by szcze...@gmail.com on 14 Jul 2009 at 2:54