Exemple sur l’argument de MockitoCaptor

Quelqu’un peut-il s’il vous plaît me fournir un exemple montrant quelle est l’utilisation de la classe org.mockito.ArgumentCaptor et comment il est différent des simples matchers fournis avec mockito.

J’ai lu les documents mockito fournis mais ceux-ci ne l’illustrent pas clairement, ils ne sont pas non plus en mesure de l’expliquer clairement.

Je suis plus d’accord avec ce que @fge a dit. Regardons par exemple. Considérez que vous avez une méthode:

 class A { public void foo(OtherClass other) { SomeData data = new SomeData("Some inner data"); other.doSomething(data); } } 

Maintenant, si vous souhaitez vérifier les données internes, vous pouvez utiliser le capteur:

 // Create a mock of the OtherClass OtherClass other = mock(OtherClass.class); // Run the foo method with the mock new A().foo(other); // Capture the argument of the doSomething function ArgumentCaptor captor = ArgumentCaptor.forClass(SomeData.class); verify(other, times(1)).doSomething(captor.capture()); // Assert the argument SomeData actual = captor.getValue(); assertEquals("Some inner data", actual.innerData); 

Les deux principales différences sont les suivantes:

  • Lorsque vous capturez même un seul argument, vous pouvez effectuer des tests beaucoup plus élaborés sur cet argument, avec un code plus évident.
  • un ArgumentCaptor peut capturer plusieurs fois.

Pour illustrer ce dernier, disons que vous avez:

 final ArgumentCaptor captor = ArgumentCaptor.forClass(Foo.class); verify(x, times(4)).someMethod(captor.capture()); // for instance 

Ensuite, le capteur pourra vous donner access aux 4 arguments, sur lesquels vous pourrez ensuite effectuer des assertions séparément.

Ceci ou n’importe quel nombre d’arguments en fait, car un VerificationMode n’est pas limité à un nombre fixe d’appels; En tout état de cause, le ravisseur vous donnera access à tous, si vous le souhaitez.

Cela a également l’avantage que de tels tests sont beaucoup plus faciles à écrire que de devoir implémenter votre propre ArgumentMatcher , en particulier si vous combinez mockito avec assertj.

Oh, et s’il vous plaît envisager d’utiliser TestNG au lieu de JUnit.

Considérons un scénario où nous testons une méthode qui dépend d’un collaborateur. Ce collaborateur prend un argument en appelant l’une de ses méthodes. Maintenant, il peut y avoir deux scénarios: 1. L’argument est transmis en externe à la méthode que nous testons, puis utilisé par le collaborateur pendant son propre appel de méthode.

  method(argument arg) { collaborator.callMethod(arg); } 

Pour tester cette méthode, nous nous moquons du collaborateur puis appelons la méthode comme suit

 method(arg1); Mockito.verify(collaborator).callMethod(arg1); 

Donc, ici, dans la méthode de test, nous avons l’instance arg1 et peut donc être vérifiée
2. L’argument utilisé par le collaborateur pour effectuer son propre appel de méthode n’est pas transmis en externe et créé dans la méthode testée.

 method() { arg=CreateArgumentInternally(); collaborator.callMethod(arg); } 

Pour tester cette méthode, nous nous moquons du collaborateur puis appelons la méthode comme suit

méthode();

Mais comment vérifier que le collaborateur a été appelé avec quels arguments puisque nous n’avons pas access à l’argument tel qu’il a été créé en interne dans la méthode. C’est là que le Mockito ArgumentCaptor apparaît.
En utilisant ArgumentCaptor, nous pouvons obtenir l’instance d’argument créée en interne et utilisée dans l’appel collaborateur, ce qui nous permet de le vérifier.

 Mockito.verify(collaborator).callMethod(captor.capture()); Argument actual = captor.getValue(); 

Référence – Comprendre Mockito ArgumentCaptor à l’aide de l’exemple de test de démarrage Spring