Mockito - Difference Between Doreturn() and When()

Mockito - difference between doReturn() and when()

The two syntaxes for stubbing are roughly equivalent. However, you can always use doReturn/when for stubbing; but there are cases where you can't use when/thenReturn. Stubbing void methods is one such. Others include use with Mockito spies, and stubbing the same method more than once.

One thing that when/thenReturn gives you, that doReturn/when doesn't, is type-checking of the value that you're returning, at compile time. However, I believe this is of almost no value - if you've got the type wrong, you'll find out as soon as you run your test.

I strongly recommend only using doReturn/when. There is no point in learning two syntaxes when one will do.

You may wish to refer to my answer at Forming Mockito "grammars" - a more detailed answer to a very closely related question.

why Mock object has doreturn and thenreturn for mock?

After doing by my own I came to know that:

  1. doreturn/when and when/thenreturn are same for mocked object. None of them call the actual method
  2. doreturn/when and when/thenreturn have different behaviour for spied object.
    doreturn/when - it will not call real method on spied object
    when/thenreturn - it will call real method on spied object

Hope it helps!

How are doReturn and toReturn different in Mockito?

stub(T).toReturn(...) is just a deprecated syntax replaced by when(T).thenReturn(...). Same rules and guidelines apply as in the question you linked:

  • when().thenReturn() and stub().toReturn() can do return type checking
  • doAnswer().when() is the only way to stub void methods
  • doReturn().when() avoids calling the real method in spies and already-stubbed objects

Otherwise, they have exactly the same behavior and the same consequences, and can be used interchangeably.

Mockito doReturn().when() calls original method

Instead of using the null parameters to setup the mocked storeContent method I would suggest using ArgumentMatchers.any

E.g.

import static org.mockito.ArgumentMatchers.*;

// ...

Mockito.doReturn("This is not the method you are looking for").when(classToTest).storeContent(any(), any(), any());

Mockito not detecting call on repository of service when using doReturn instead of whenThen

You are making the same mistake in both of your code snippets, in that you're stubbing a method in the class that you're trying to test, instead of stubbing the method in the mocked class.

This means that you're effectively just testing the stubbing, not testing the class itself.

What you want to do is

  1. Get rid of the Spy annotation - you don't need a spy for this.
  2. Stub the method of the repository class, not the service class.

That way, you'll be testing that the service class calls the repository class correctly, and handles the response from the repository class correctly. But you'll also be circumventing the implementation of the repository class, which is the whole point of using a mock.

In Mockito, what's the proper way to return different results upon conseuctive calls to a non-static method?

Mockito.when(connection.query(Mockito.anyString())).thenReturn(queryResults1).thenReturn(queryResults2);

Since you dont want the query to be executed you should use this format
doReturn(...).when(..).

Mockito.doReturn(queryResults1).doReturn(queryResults2).when(connection).query(Mockito.anyString())

There is no difference between the above statements if you mock the oject. But if you are using spy, When(...).thenReturn() will call the real method first before returning. So you should use doReturn(...).when(..) in this case.

More about it here

mockito, when setup mock stub using when/thenReturn it got exception

From Mockito doc:

Sometimes it's impossible or impractical to use when(Object) for
stubbing spies. Therefore when using spies please consider
doReturn|Answer|Throw() family of methods for stubbing.

So try it so:

  doReturn(fakeCookieList).when(theSpy)
.mergeList(eq(aCookieList), any(HttpCookie.class));

But in general it is not quite clear what you are testing with such a test. The method under test is mergeList, at the same time you specify its behavior(return value) by calling doReturn and only returned value is checked in the end. (Of course, if the real code is fully represented)



Related Topics



Leave a reply



Submit