MockitoJUnitRunnervous donne une validation automatique de l'utilisation du framework, ainsi qu'un automatique initMocks().
La validation automatique de l'utilisation du framework en vaut la peine. Cela vous donne de meilleurs rapports si vous faites l'une de ces erreurs.
Vous appelez la whenméthode statique , mais ne terminez pas le stubbing avec une correspondance thenReturn, thenThrowou then. (Erreur 1 dans le code ci-dessous)
Vous appelez verifyun simulacre, mais oubliez de fournir l'appel de méthode que vous essayez de vérifier. (Erreur 2 dans le code ci-dessous)
Vous appelez la whenméthode après doReturn, doThrowou
doAnsweret passez une maquette, mais oubliez de fournir la méthode que vous essayez de talon. (Erreur 3 dans le code ci-dessous)
Si vous n'avez pas de validation de l'utilisation du framework, ces erreurs ne sont pas signalées jusqu'à l' appel suivant à une méthode Mockito. Cela pourrait être
- dans la même méthode de test (comme l'erreur 1 ci-dessous),
- dans la méthode de test suivante (comme l'erreur 2 ci-dessous),
- dans la classe de test suivante.
S'ils se produisent lors du dernier test que vous exécutez (comme l'erreur 3 ci-dessous), ils ne seront pas signalés du tout.
Voici à quoi pourrait ressembler chacun de ces types d'erreurs. Supposons ici que JUnit exécute ces tests dans l'ordre dans lequel ils sont répertoriés ici.
@Test
public void test1() {
// ERROR 1
// This compiles and runs, but it's an invalid use of the framework because
// Mockito is still waiting to find out what it should do when myMethod is called.
// But Mockito can't report it yet, because the call to thenReturn might
// be yet to happen.
when(myMock.method1());
doSomeTestingStuff();
// ERROR 1 is reported on the following line, even though it's not the line with
// the error.
verify(myMock).method2();
}
@Test
public void test2() {
doSomeTestingStuff();
// ERROR 2
// This compiles and runs, but it's an invalid use of the framework because
// Mockito doesn't know what method call to verify. But Mockito can't report
// it yet, because the call to the method that's being verified might
// be yet to happen.
verify(myMock);
}
@Test
public void test3() {
// ERROR 2 is reported on the following line, even though it's not even in
// the same test as the error.
doReturn("Hello").when(myMock).method1();
// ERROR 3
// This compiles and runs, but it's an invalid use of the framework because
// Mockito doesn't know what method call is being stubbed. But Mockito can't
// report it yet, because the call to the method that's being stubbed might
// be yet to happen.
doReturn("World").when(myMock);
doSomeTestingStuff();
// ERROR 3 is never reported, because there are no more Mockito calls.
}
Maintenant, quand j'ai écrit cette réponse pour la première fois il y a plus de cinq ans, j'ai écrit
Je recommanderais donc l'utilisation du dans la MockitoJUnitRunnermesure du possible. Cependant, comme Tomasz Nurkiewicz l'a correctement souligné, vous ne pouvez pas l'utiliser si vous avez besoin d'un autre runner JUnit, tel que celui de Spring.
Ma recommandation a maintenant changé. L'équipe Mockito a ajouté une nouvelle fonctionnalité depuis que j'ai écrit cette réponse pour la première fois. C'est une règle JUnit, qui exécute exactement la même fonction que le MockitoJUnitRunner. Mais c'est mieux, car cela n'empêche pas l'utilisation d'autres coureurs.
Comprendre
@Rule
public MockitoRule rule = MockitoJUnit.rule();
dans votre classe de test. Cela initialise les simulations et automatise la validation du framework; tout comme le MockitoJUnitRunnerfait. Mais maintenant, vous pouvez également utiliser SpringJUnit4ClassRunnerou tout autre JUnitRunner. À partir de Mockito 2.1.0, il existe des options supplémentaires qui contrôlent exactement le type de problème signalé.