2010-11-24 32 views
6

Nous essayons de vérifier le comportement d'une action avec Mockito. Le code de test ressemble à ceMockito se plaint de mauvais arguments

final Type1 mock = mock(Type1.class); 
new SomeAction<Type1>(mock).actionPerformed(null); 

verify(mock).someMethod(); 

La méthode actionPerformed ne contient que l'appel de someMethod sur l'objet fourni dans le constructeur de Type1. Pourtant Mockito se plaint que l'appel de méthode attendu n'a pas eu lieu, à la place un appel de méthode différent est arrivé. Mais la représentation en chaîne des deux appels imprimés par Mockito est exactement la même!

Une explication de ce qui se passe?

Mise à jour: ErrorMessage de Mockito

Argument(s) are different! Wanted: 
type1.someMethod(); 
-> at xxx 
Actual invocation has different arguments: 
type1.someMethod(); 
-> at xxx 
+0

Je l'ai essayé, et cela a fonctionné comme prévu (vérifier les passes). Quelle version de Mockito utilisez-vous? Je suis sur 1.8. Êtes-vous sûr que votre paramètre null ne provoque pas la prise d'une branche différente? – omerkudat

+0

La version est 1.8.5; someMethod est un oneliner, donc il n'y a vraiment pas de partie différente. –

+0

Pourriez-vous fournir un SSCCE s'il vous plaît? – daveb

Répondre

3

Ceci est un peu exagéré, mais il faut vérifier vos implémentations toString. Je me suis heurté à des scénarios de tests unitaires agaçants où les attentes et les observations semblaient être les mêmes du point de vue des tests unitaires alors qu'en réalité ils étaient différents. En fin de compte c'était une variation dans toString qui m'a fait croire qu'il y avait une similitude alors qu'en réalité il n'y en avait pas.

+0

puisque la méthode retourne void et ne prend pas d'arguments il n'y a pas de toString impliqué ... Je pense. –

+0

La représentation toString() affichée dans le résultat du test unitaire m'a trompé une fois. Pour savoir si les deux objets sur lesquels Mockito se plaignait sont ou non différents, j'ai redéfini toString comme dans Object. –