Mockito - différence entre doReturn () et when ()

Je suis actuellement en train d'utiliser Mockito pour simuler mes objets de couche de service dans une application Spring MVC dans laquelle je veux tester mes méthodes de contrôleur. Cependant, comme je l'ai lu sur les spécificités de Mockito, j'ai trouvé que les méthodes étaient doReturn(...).when(...)équivalentes à when(...).thenReturn(...). Donc, ma question est quel est l'intérêt d'avoir deux méthodes qui font la même chose ou quelle est la différence subtile entre doReturn(...).when(...)et when(...).thenReturn(...)?

Toute aide serait appréciée.

Les deux syntaxes pour le stubbing sont à peu près équivalentes. Cependant, vous pouvez toujours utiliser doReturn/whenpour le tronçonnage; mais il y a des cas où vous ne pouvez pas utiliser when/thenReturn. Les méthodes de stubbing void en font partie. D'autres incluent l'utilisation avec des espions Mockito et le tronçonnage de la même méthode plus d'une fois.

Une chose qui when/thenReturnvous donne, ce doReturn/whenn'est pas le cas, est la vérification de type de la valeur que vous retournez, au moment de la compilation. Cependant, je crois que cela n'a presque aucune valeur - si vous avez un mauvais type, vous le saurez dès que vous exécuterez votre test.

Je recommande fortement d'utiliser uniquement doReturn/when. Il ne sert à rien d'apprendre deux syntaxes quand on le fera.

Vous voudrez peut-être vous référer à ma réponse à Forming Mockito "grammars" - une réponse plus détaillée à une question très proche.

Les deux approches se comportent différemment si vous utilisez un objet espion (annoté avec @Spy) au lieu d'une maquette (annoté avec @Mock):

• when(...) thenReturn(...) effectue un véritable appel de méthode juste avant que la valeur spécifiée ne soit renvoyée. Donc, si la méthode appelée lève une exception, vous devez y faire face / la mocker etc. Bien sûr, vous obtenez toujours votre résultat (ce que vous définissez dans thenReturn(...))

• doReturn(...) when(...) n'appelle pas du tout la méthode .

Exemple:

public class MyClass {
     protected String methodToBeTested() {
           return anotherMethodInClass();
     }

     protected String anotherMethodInClass() {
          throw new NullPointerException();
     }
}

Tester:

@Spy
private MyClass myClass;

// ...

// would work fine
doReturn("test").when(myClass).anotherMethodInClass();

// would throw a NullPointerException
when(myClass.anotherMethodInClass()).thenReturn("test");

Le javadoc Mockito semble dire pourquoi utiliser doReturn()au lieu d' when() utiliser Utiliser doReturn () dans les rares occasions où vous ne pouvez pas utiliser Mockito.when (Object).

Attention, Mockito.when (Object) est toujours recommandé pour le stubbing car il est sûr pour les arguments et plus lisible (en particulier lors du stubbing d'appels consécutifs).

Voici ces rares occasions où doReturn () est utile:

1. Quand espionner de vrais objets et appeler de vraies méthodes sur un espion apporte des effets secondaires

List list = new LinkedList(); List spy = spy(list);

// Impossible: la vraie méthode est appelée alors spy.get (0) lève IndexOutOfBoundsException (la liste est encore vide)

when(spy.get(0)).thenReturn("foo");

// Vous devez utiliser doReturn () pour le stubbing: doReturn("foo").when(spy).get(0);

2. Remplacer un stubbing d'exception précédent:

when(mock.foo()).thenThrow(new RuntimeException());

// Impossible: la méthode foo () tronquée d'exception est appelée, de sorte que RuntimeException est levée. when(mock.foo()).thenReturn("bar");

// Vous devez utiliser doReturn () pour le stubbing:

doReturn("bar").when(mock).foo(); Les scénarios ci-dessus montrent un compromis entre l'élégante syntaxe de Mockito. Notez cependant que les scénarios sont très rares. L'espionnage doit être sporadique et le tronçonnage d'exception est très rare. Sans oublier qu'en général, le remplacement du stubbing est une odeur de code potentielle qui indique trop de stubbing.

Poursuivant cette réponse , il y a une autre différence que si vous voulez que votre méthode retourne des valeurs différentes par exemple quand elle est appelée pour la première fois, pour la deuxième fois, etc., vous pouvez passer des valeurs donc par exemple ...

PowerMockito.doReturn(false, false, true).when(SomeClass.class, "SomeMethod", Matchers.any(SomeClass.class));

Ainsi, elle renverra false lorsque la méthode est appelée dans le même scénario de test, puis elle renverra à nouveau et enfin true.

Cette dernière alternative est utilisée pour les méthodes sur les simulations qui reviennent void.

Veuillez jeter un œil, par exemple, ici: Comment faire des méthodes de mock to void avec mockito