cannot use argument matchers in nested calls when doing verify

[GoogleCodeExporter]

What steps will reproduce the problem?
SomeClass mock = mock(SomeClass.class);
mock.nestedCall("someString").callToVerify();
verify(mock.nestedCall(anyString())).callToVerify();

What is the expected output? What do you see instead?
Verify should succeed but fails 

What version of the product are you using? On what operating system?
mockito 1.8.5 and mockito 1.9.1-SNAPSHOT on windows xp

Please provide any additional information below.
In the verify line, mockito figures out which stub to return for the nestedCall 
based on the actual arguments passed in, not for the registered matchers. In 
this case, the value returned by anyString() is "", which does not match 
"someString", so a different mock is returned than the one returned in the 
second line. I've created a clone of mockito with a fix to this issue and a 
corresponding tests here: 
https://EricKucks@code.google.com/r/erickucks-nested-call-argument-matchers/ 
erickucks-nested-call-argument-matchers  

Original issue reported on code.google.com by EricKu...@gmail.com on 3 Aug 2011 at 6:40

[GoogleCodeExporter]

Thx Eric for your patch. I'll look into it.

Original comment by brice.du...@gmail.com on 7 Oct 2011 at 1:25

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Sorry for late feedback - I think I don't understand the use case fully. @Eric, 
can you elaborate a bit why you need to do the nested call? BTW. We'are 
planning the next release and we're thinking on including the issue.

Cheers!

Original comment by szcze...@gmail.com on 23 Oct 2011 at 8:00

[GoogleCodeExporter]

You mean the container.getInvocationForStubbing().matches()? I submitted a 
change that moves that whole for loop logic into 
InvocationContainerImpl.answerToCurrentInvocationMatcher() and changed it to 
closely match answerTo(Invocation).

Also, just to clarify the surrounding issue. When the code under test executes 
a nested mock call, the ReturnsDeepStubs creates an Answer to return the mock. 
Later, when the verify is called the code looks like this:

verify(aMock.someCall(anyString())).nestedCall();

When aMock.someCall(anyString()) is called, the MockHandler calls 
invocationContainerImpl.findAnswerFor because it doesn't know it's in verify 
mode yet so it behaves like this is testable code executing. The findAnswerFor 
will only match the answer created by ReturnsDeepStubs during testable code 
execution if the arguments to the call wrapped in the verify match exactly, 
since the testable code won't pass in argument matchers like we would if were 
doing a when statement. So the solution was to reverse the process and instead 
of comparing the current invocation to a list of previous stubbed invocation 
matchers we instead take the current invocation matcher and compare it to 
previous invocations. This way the original Answer that created the mock used 
in the testable code is returned by aMock.someCall(anyString()) and 
expectations can be checked against it.

Original comment by EricKu...@gmail.com on 26 Oct 2011 at 4:28

[GoogleCodeExporter]

I actually tried it at home, it seems to be working and don't seem to break 
other tests, assuming we got it completely covered of course. Aside from that I 
suppose this way of remembering which mocks were issued regardless of 
verification, seems ok to me for deep stubs.

However this patch could wait the 1.9.1.

Original comment by brice.du...@gmail.com on 26 Oct 2011 at 4:39

[GoogleCodeExporter]

Ok, makes sense.

Original comment by szcze...@gmail.com on 27 Oct 2011 at 6:13

[GoogleCodeExporter]

Ok, i'll commit something this afternon

Original comment by brice.du...@gmail.com on 27 Oct 2011 at 11:05

• Changed state: Started

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 28 Oct 2011 at 5:20

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 13 May 2012 at 3:37

• Added labels: Milestone-Release1.9.5

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 3 Jun 2012 at 2:06

• Added labels: Milestone-Release1.9.5-rc1
• Removed labels: Milestone-Release1.9.5

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 2 Dec 2012 at 10:21

• Added labels: Matchers