J'utilise Mockito pour écrire des tests pour le code. Cependant, je suis coincé au scénario suivant - La classe A a 2 méthodes, la méthode1 () et la méthode2 (). J'ai essayé d'utiliser ArgumentCaptor pour attraper des valeurs envoyées à la méthode2 (). Mais, puisque j'utilise @spy, je ne peux pas utiliser de correspondants.
Comment puis-je tester la méthode1 ()? Comment vérifier la méthode2 reçoit les mêmes valeurs d'argument?
Voici la classe de test que j'ai écrit: }
3 Réponses :
Vous ne pouvez pas, vous devez le vérifier par la méthode de B de B. Si vos arguments à la méthode2 n'ont aucun effet sur la méthode3, Theses args pourrait être inutile du tout ?!
Désolé, j'ai modifié le code d'échantillon pour refléter les arguments transmis à la méthode3. Oui, je pourrais vérifier la méthode 3 appel. Je me demande si j'écris le test correctement? Parce que je n'ai pas vu des exemples avec espion et injectmocks conjonction. Existe-t-il une meilleure approche pour écrire le cas de test?
Vous pouvez utiliser des correspondants avec des espions; Cela fonctionne juste bien. Je ne sais pas pourquoi tu pensais que tu ne pouvais pas.
J'ai pris votre code source et je l'ai édité pour le faire compiler. J'ai ensuite ajouté un appel à Donc, contrairement à la réponse de Omnaest, vous n'avez pas besoin d'utiliser la méthode bonne chance avec cela, et n'hésitez pas à poster à nouveau si vous avez besoin d'une aide supplémentaire. mockitoannotations.initmocks - vous avez besoin de ceci pour créer l'espion et la maquette et pour injecter la simule (sauf si vous n'utilisez pas le MockitojuniRunner , qui fait le initmocks pour vous). Je mets le vérifier de l'appel à méthodal2 dans. Cela a fonctionné bien.
de B de B '/ code> pour vérifier cela. Je soupçonne que votre seul problème était que vous aviez oublié le initmocks .
Oui, vous avez raison, CGLIB étend-vous vraiment la classe. Il peut donc remplacer la méthode2 et peut donc capturer des appels internes. Donc, fondamentalement mockito peut le faire dans le cas exactement. Néanmoins, je n'ai jamais vu cela dans de vraies applications, car les méthodes internes sont la plupart des cas déclarées comme privées. Vous êtes donc obligé de déclarer des méthodes internes au moins avec un emballage ou protégé. Je ne sais pas si c'est une bonne approche du tout. Mais toujours la question semble pointer sur les capacités de Mockito, si définitivement oui, cela fonctionne.
C'est vrai, je ne dis pas que c'est une bonne approche. Mais lorsque le code source fourni est dépouillé jusqu'au point où nous ne pouvons pas dire ce que l'OP tente de faire, c'était la meilleure réponse que je puisse fournir. Il y a peut-être une question plus profonde, dans le sens de "Comment puis-je tester la meilleure unité à tester une classe XYZ" - mais malheureusement cette question n'a pas été posée, nous ne pouvons donc pas réellement voir quel test de test l'OP tente résoudre.
@Davidwallace: J'utilisais Annotation de Runwith (MockitojunitruRunner.class) et quand j'ai essayé 'Vérifiez (A, Times (1)). Méthode2 (.......)', l'exception est Verify () être utilisé avec des objets simulés . Et j'ai la question: "Est-ce la meilleure façon de tester ce scénario"? Je suis nouveau à moquer et j'apprend toujours en expérimentant.
Ok, je viens d'essayer à nouveau de nouveau, en utilisant le Mockitojunntrunner au lieu d'appeler initmocks directement. Le test passe toujours pour moi; Il n'y a pas d'exception. J'ai utilisé Mockito 1.9.0-RC1, mais je ne crois pas que rien dans cette zone ait changé entre RC1 et la libération officielle de 1.9.0. Quelle version de Mockito avez-vous, de sorte que je puisse continuer à essayer de reproduire votre problème?
@Davidwallace - Oui, j'utilise la dernière version de Mockito 1.9.0. Je n'ai pas le message d'erreur exact que j'ai eu plus tôt. Quoi qu'il en soit, cela fonctionne maintenant. Merci.
Ok, je vais arrêter d'essayer de reproduire votre erreur. En réponse à votre question "Est-ce le meilleur moyen de tester ce scénario", c'est un peu difficile de le dire, car nous ne savons pas que le scénario est. Je suppose que c'est probablement pas; Vérification des espions pointe souvent des tests mal conçus, mais tout cela est un peu hors contexte. Quels tests vous écrivez devraient toujours dépendre de plus sur le comportement que vous essayez de tester, que sur le Mécanisme que vous avez utilisé pour mettre en œuvre ce comportement. Je vous conseillerais de poster une question distincte - décrivez le comportement que vous essayez de tester et de demander des suggestions.
@ pas, vous devez accepter cela comme la bonne réponse. Je n'ai presque pas lu après avoir vu cela comme la réponse actuellement acceptée avec un classement plus élevé que celui-ci.
J'ai été intrigué par ce post et les commentaires laissés par @david alors j'ai décidé de coder un exemple de travail pour ceux qui suivent comme moi Nous voulons affirmer que la valeur étant adoptée dans la méthodeb () est ce que nous attendons. Lire sur le ArgumentCaptor m'a conduit à découvrir l'équivalent AnnotationCaptor P> import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.verify;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.ArgumentCaptor;
import org.mockito.Captor;
import org.mockito.Spy;
import org.mockito.runners.MockitoJUnitRunner;
@RunWith(MockitoJUnitRunner.class)
public class MultipleMethodCallTest {
@Spy
A a = new A();
@Captor ArgumentCaptor<String> captor;
@Test
public void captureSecondMethodCallArgument() throws Exception {
// EXPECTED
String greeting = "hello world";
// PERFORM TEST
a.methodA(greeting);
// ASSERT
verify(a).methodB(captor.capture());
assertEquals(greeting, captor.getValue());
}
}
Voir la réponse de @dawood Ibn Kareem ci-dessous. Stackoverflow.com/a/10292649/3477577 C'est la bonne réponse.
J'ai ajouté un exemple codé comme une réponse basée sur votre discussion avec David