Tests unitaires avec mockito (partielle moqueur)
J'ai un problème avec Mockito.
Est-il possible de faire une telle chose:
ClassX x = mock(ClassX.class)
when(x.methodB()).thenReturn("toto");
String result = x.methodA();
Je travaille avec Mockito 1.7.
J'ai vu qu'il y avait un "espion" du système mais ils disent qu'il n'est pas recommandé de l'utiliser (pourquoi?) sur l'article que nous tester...
J'ai essayé d'espionnage de la fonction, de toute façon mais j'ai un comportement étrange.
Vérifier ce que je veux faire:
Code réel:
String methodA(String arg) {
return this.methodB(arg);
}
String methodB(String arg) {
return "toto";
}
Code de Test:
@Test
public void testTest() {
final ClassX x = spy( new ClassX() );
final String argument = "arg";
doReturn("good").when(helper).methodB(argument);
assertTrue( x.methodB(argument).equals("good") );
assertTrue( x.methodA(argument).equals("good") );
}
Comme ils l'ont dit j'ai évité lorsque thenReturn syntaxe qui pourrait être un problème avec un espion (mais il ne fonctionne pas non plus de toute façon)
La chose étrange est que:
assertTrue( x.methodB(argument).equals("bon") );
est OK
Seulement la deuxième
assertTrue( x.methodA(argument).equals("bon") );
n'est pas OK
Fait helper.methodA(argument) renvoie "toto" -> le résultat réel, et non le simulacre résultat
Il n'est pas possible de dire mockito de retour "bon" dans ce cas??? Il semble que lorsque la classe de test appel methodB c'est ok, mais si une méthode de l'espion appelle la methodB il ne fonctionne plus...
Je ne sais pas quoi faire... est-ce une chose étrange à l'unité-test 2 méthodes de la même classe et de faire les tests indépendants les uns des autres de sorte qu'un célèbre simulation d'essai framework ne pas mettre en œuvre cette fonction de base? N'est-ce pas ce que nous venons d'appel réel de tests unitaires? Ne comprends pas pourquoi ils disent d'éviter d'utiliser de l'espion de la méthode sur l'objet testé...
Grâce
"good"
. Donc je suppose que ce problème est disparu.OriginalL'auteur Sebastien Lorber | 2010-11-22
Vous devez vous connecter pour publier un commentaire.
Le spy est un autre objet à partir de la espionné objet. L'espion seuls les délégués à la espionné objet. Ainsi, lorsque le espionné objet d'appels methodB de methodA, il va appeler sur elle-même, et non pas sur l'espion.
Je suppose que je pourrais utiliser un anonyme réel de la classe et de remplacer MethodB mais mockito ne donne pas une bonne pour cette solution?
Au lieu de mettre
methodB
sur un autre objet que vous fournissez comme une dépendance de l'objet qui amethodA
, par exemple en tant que paramètre du constructeur. De cette façon, vous pouvez vous moquer de lamethodB
objet. Si vous donnez le nom de vos objets et méthodes, je peux suggérer de meilleurs noms pour vous.Merci. Donc, il semble qu'il n'y a pas de solution à l'utilisation d'espionnage et de mettre les 2 méthodes dans la même classe... triste
devrait
methodB
être déplacé juste pour le plaisir de se moquer et de test, même si (1) les deuxmethodA
etmethodB
carrément appartiennent à la même classe, et (2)methodB
est un morceau de code commun quimethodA
utilise?OriginalL'auteur Christoffer Hammarström
Mise à JOUR:
J'ai écrit les trucs ci-dessous, puis quelques instants plus tard découvert .thenCallRealMethod() qui permet d'effectuer de manière partiellement cogner. Mockito auteurs vous recommandons l'utilisation de refactoring pour séparer les dépendances dans des classes différentes; mais ils fournissent les moyens d'partiellement stub. J'ai ajouté une méthode d'essai pour illustrer cette approche, et de laisser mes commentaires d'origine.
ORIGINAL:
J'aime vraiment Mockito, mais c'est la seule place où EasyMock qui l'emporte. J'ai deux solutions pour vous qui n'impliquent pas de Mockito. La première est de remplacer methodB sur vos tests instance. L'autre est partiellement fictif avec EasyMock:
OriginalL'auteur Fred Haslam