Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Mockito complains about wrong arguments

We try to verify the behaviour of an action with Mockito. The test code looks like this

final Type1 mock = mock(Type1.class);
new SomeAction<Type1>(mock).actionPerformed(null);

verify(mock).someMethod();

The method actionPerformed contains just the call of someMethod on the object provided in the constructor of Type1. Yet Mockito complains that the expected method call did not happen, instead a different method call happened. But the String representation of the two calls printed by Mockito are exactly the same!

Any explanation what is going on?

Update: ErrorMessage from Mockito

Argument(s) are different! Wanted:
type1.someMethod();
-> at xxx
Actual invocation has different arguments:
type1.someMethod();
-> at xxx
like image 201
Jens Schauder Avatar asked Nov 24 '10 11:11

Jens Schauder


People also ask

What can I use instead of Mockito matchers?

Since Mockito any(Class) and anyInt family matchers perform a type check, thus they won't match null arguments. Instead use the isNull matcher.

What is stubbing in Mockito?

A stub is a fake class that comes with preprogrammed return values. It's injected into the class under test to give you absolute control over what's being tested as input. A typical stub is a database connection that allows you to mimic any scenario without having a real database.

Should you use Mockito verify?

Mockito verify() method can be used to test number of method invocations too. We can test exact number of times, at least once, at least, at most number of invocation times for a mocked method. We can use verifyNoMoreInteractions() after all the verify() method calls to make sure everything is verified.

What does Mockito any () do?

Mockito allows us to create mock objects and stub the behavior for our test cases. We usually mock the behavior using when() and thenReturn() on the mock object.


1 Answers

This is a bit of a stretch, but check your toString implementations. I've ran into some irritating unit test scenarios where the expected and observed appeared to be the same from the unit test point of view when in reality they were different. In the end it was a variation in toString that caused me to believe there was a similarity when in reality there was not.

like image 161
javamonkey79 Avatar answered Oct 04 '22 01:10

javamonkey79