how does verify count invocations

[ich du]

in my test i have many invocations of the same method but with different parameter.

until now i thought mockito counts per parameter set but it seems it counts only per method - is this right?

for example my failing test look like this ("..." are provoking another call of method)

verify(myMock).method(object1);

...

verify(myMock).method(object2);

...

verify(myMock).method(object3);

...

verify(myMock).method(object4);

All object are not "equal"!

But this is working:

verify(myMock).method(object1);

...

verify(myMock,times(2)).method(object2);

...

verify(myMock,times(3)).method(object3);

...

verify(myMock,times(4)).method(object4);

is this working as intended? Probably i misunderstood the semantic: i thought: "method was called exactly once with parameter equal to object4", but it seems "method was called 4 times and at least one time with parameter object4. Is this right or am i terribly wrong?

[Eric Lefevre-Ardant]

I think your understanding of the behavior of Mockito is right.

Is it possible that the equals() method for your object is actually not working as you think?

--
You received this message because you are subscribed to the Google Groups "mockito" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mockito/-/e0Hxp-9UIcoJ.
To post to this group, send email to moc...@googlegroups.com.
To unsubscribe from this group, send email to mockito+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mockito?hl=en.

[ich du]

what understanding is right?- my actual (one count per method) or my previous(one count per method(parameter combination)) understanding?

the equal is working i debugged the problem for some hours including sysouts of object1==object2 -->false.

i also set breakpoint on all calls in test object -> per object(-hash) there is exactly one call but verify only passes if i sum all calls regardless of parameter.

the problem is i need to understand why my first attempt is failing and my second one is passing. the problem becomes even more strange because the code now looks like this:

this is passing:

verify(myMock,times(2)).method(object1); //method is called 2 times with an object equal to object1 - on 2 different lines in testobject

verifyNoMoreInteractions(myMock);

...

verify(myMock,times(2)).method(object2); //method is called 1 time with object2 -why 2 times and not 4?

verifyNoMoreInteractions(myMock)

...

verify(myMock,times(3)).method(object3);//same here

verifyNoMoreInteractions(myMock)

...

verify(myMock,times(4)).method(object4);//same here

verifyNoMoreInteractions(myMock)

Is there any way to debug the mocks? - to see when they are called and what parameters they get? With information on debugging the testobject (checking each method call) and debugging the verify calls (checking the parameters) the only explanation why the above test is passing is my "new understanding".

To unsubscribe from this group, send email to mockito+unsubscribe@googlegroups.com.

[Russell Bateman]

It could be I'm not patient enough with the doc and examples out there, but I'm confused about what the right way is to verify that my method under test throws the exception I want it to throw under the circumstances and how to end my JUnit test method gracefully in consequence thereof.

I have already got the test for the working case functioning properly; now I'm writing to verify my class/method fails "properly".

Schematically, I have:

- set-up of objects
- when clauses
- call to method that should throw my own AppException
- verify clause*
- assert this, that and the other thing clauses

I'm thinking that here, I should be able to say something tantamount to

verify( object ).method( args ).throws( AppException )

...or something like that.

Many thanks for help or a nudge forward with this,

Russ Bateman

[Holger Hoffstätte]

On 07/30/12 17:16, Russell Bateman wrote:
> I'm thinking that here, I should be able to say something tantamount to
>
> verify( object ).method( args ).throws( AppException )
>
> ...or something like that.

This would obscure several potentially valuable details post-throw. So
far I've always used the somewhat pedestrian:

try
{
mock.boom();
fail("no boom");
}
catch (BoomException boom)
{
// verify specific details, required/absent side effects etc.
}

Yes, it's more verbose. It also allows for exact inspection &
verification of possible side-effects, type/details on the thrown
exception, zero stray calls to other mocks etc.

Alternatively save the boilerplate and just mark your test method with
an appropriate JUnit expectation.

-h

[Tomek Kaczanowski]

Hi Russell,

have you tried http://code.google.com/p/catch-exception/ ?

--
Regards / Pozdrawiam
Tomek Kaczanowski
http://practicalunittesting.com

[Russell Bateman]

It could be that I have ill-explained myself. I'm not concerned with creating the case where my mocked class would throw an exception, but with allowing my class under test to throw an exception as the behavior I expect.

Thus, stuff like:

when( foo() ).thenThrow( exception )

isn't what I'm looking for. (It could be that the semantics of when vs verify aren't how I expect them to be., but I'll press on a little further before throwing in the towel.)

Conversely, your suggestion of rigging JUnit to be happy with the exception is definitely something to look at.

Thank you for responding,

Russ

[Russell Bateman]

Hmmmm... this show great promise. I'll check it out. I was thinking I'd
still be "verifying" under Mockito control, but this might be fine since
there are no additional verifications or assertions I'm interested in
conducting.

Thanks very much,

Russ

[Simon Brunning]

On 30 July 2012 17:07, Russell Bateman <ru...@windofkeltia.com> wrote:
> It could be that I have ill-explained myself. I'm not concerned with
> creating the case where my mocked class would throw an exception, but with
> allowing my class under test to throw an exception as the behavior I expect.

I normally use something like this:

// When
try {
restTemplate.put(url, jsonEntity(payload));
fail("Expected HttpClientErrorException");
} catch (HttpClientErrorException exception) {
// Then
assertThat(exception, hasStatusCode(NOT_FOUND));
}

--
Cheers,
Simon B.

[Russell Bateman]

Uh, yeah, of course. I'm starting to realize now that I was completely
over-thinking this.

Thanks for everyone's patience!

Russ

[Brice Dutheil]

At first sight the issue look indeed interesting. 

If you want to debug I suggest to take a look at the verifcation code.

Regards,

-- Brice

To view this discussion on the web visit https://groups.google.com/d/msg/mockito/-/nzd3XZO_zHEJ.

To post to this group, send email to moc...@googlegroups.com.

To unsubscribe from this group, send email to mockito+u...@googlegroups.com.