Exception Mockito dans DoThrow qui semble correcte

J’essaie de me moquer d’une méthode pour voir si je gère correctement une exception. Ceci est aussi loin que je reçois.

interface:

interface SampleManager { void deleteVariome(Ssortingng specimenId, Ssortingng analysisId) throws Exception; // ... }

Test de l’unité:

 // ... SampleManger sampleManager = mock(SampleManager.class); // below is line 753 doThrow(Exception.class).when(sampleManager).deleteVariome(sample1.getId(), analysisId);

résultat:

 org.mockito.exceptions.misusing.UnfinishedStubbingException: Unfinished stubbing detected here: -> at ...server.ArchiveManagerImplUTest.deleteVariomeFails(ArchiveManagerImplUTest.java:753) Eg thenReturn() may be missing. Examples of correct stubbing: when(mock.isOk()).thenReturn(true); when(mock.isOk()).thenThrow(exception); doThrow(exception).when(mock).someVoidMethod(); <-- this looks a log like what I did! Hints: 1. missing thenReturn() 2. you are trying to stub a final method, you naughty developer! <-- I have a lot of other mocks of this interface in this test that work.

D’un problème identique que je viens de rencontrer, je suppose que cet sample est un simulacre et que vous avez sample.getId() ailleurs? Cela a causé ce problème dans mon cas, de toute façon.

Pour une raison quelconque, Mockito est contrarié si l’un des arguments que vous transmettez au stub utilisé avec doThrow est le résultat d’une méthode que vous avez également moquée. Peut-être est-ce une sorte de vérification de réintégration pour éviter les boucles infinies, je ne sais pas.

Quoi qu’il en soit, essayez de remplacer sample.getId() par une valeur constante et cela devrait résoudre le problème. Vous pourriez envisager d’utiliser une constante déclarée dans votre test à la fois pour le simulacre et pour toute utilisation ultérieure. Vous pouvez également vérifier que sample.getId() été utilisé par la méthode que vous testez en ajoutant un autre appel à verify .

Cette erreur est généralement signalée APRÈS le lieu où elle s’est réellement produite. Si vous ne parvenez pas à stub quelque chose correctement, Mockito ne peut généralement pas le savoir jusqu’à la prochaine fois que vous appelez l’une des méthodes Mockito. Cela peut être dans la même méthode de test, une méthode de test ultérieure dans la même classe, ou même une classe de test complètement différente.

La ligne que vous avez citée me convient bien. Examinez les lignes au-dessus, où vous appelez une méthode de stoppage ou de vérification Mockito. Il est très probable que vous ayez un qui n’a pas associé thenReturn , then ou thenThrow . Ou vous pouvez avoir une verify qui manque l’appel de la méthode réelle. Il y a aussi quelques autres possibilités.

Si vous ne trouvez pas une erreur dans les lignes ci-dessus celle que vous avez citée, alors publiez un peu plus de votre code, et je vais regarder de plus près.

Comme décrit dans la réponse de Gijs, cela est probablement dû à un bug dans Mockito. Voici un test complet qui le reproduit:

 interface Sample { Ssortingng getId(); } interface SampleManager { void deleteVariome(Ssortingng specimenId, Ssortingng analysisId); } @Test public void probableMockitoBug() { Sample sample1 = mock(Sample.class); when(sample1.getId()).thenReturn("a"); SampleManager manager = mock(SampleManager.class); doThrow(Exception.class).when(manager).deleteVariome(sample1.getId(), "b"); manager.deleteVariome("a", "b"); }

Le test produit la sortie suivante:

 org.mockito.exceptions.misusing.UnfinishedStubbingException: 
 Stubbing inachevé détecté ici:
 -> à org.mockitousage.JavadocExamplesTest.probableMockitoBug (JavadocExamplesTest.java:404)

 Par exemple thenReturn () peut être manquant.
 Exemples de repérage correct:
     quand (mock.isOk ()). thenReturn (true);
     quand (mock.isOk ()). thenThrow (exception);
     doThrow (exception) .when (mock) .someVoidMethod ();
 Astuces:
  1. manquant thenReturn ()
  2. vous essayez de stub une dernière méthode, développeur coquin!

     à org.mockito.exceptions.Reporter.unfinishedStubbing (Reporter.java:55)
     à org.mockito.internal.progress.MockingProgressImpl.validateState (MockingProgressImpl.java:74)
     at org.mockito.internal.progress.ThreadSafeMockingProgress.validateState (ThreadSafeMockingProgress.java:49)
     à org.mockito.internal.MockHandler.handle (MockHandler.java:71)
     at org.mockito.internal.InvocationNotifierHandler.handle (InvocationNotifierHandler.java:36)
     à org.mockito.internal.creation.MethodInterceptorFilter.intercept (MethodInterceptorFilter.java:48)
     at org.mockitousage.JavadocExamplesTest $ Sample $$ EnhancerByMockitoWithCGLIB $$ d5ac41.getId ()
     à org.mockitousage.JavadocExamplesTest.probableMockitoBug (JavadocExamplesTest.java:404)
     à sun.reflect.NativeMethodAccessorImpl.invoke0 (méthode native)
     at org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run (JUnit45AndHigherRunnerImpl.java:37)
     à org.mockito.runners.MockitoJUnitRunner.run (MockitoJUnitRunner.java:62)

vous devez fournir une instance de Exception.class, pas la classe Exception elle-même.

 doThrow(new Exception()).when(sampleManager).deleteVariome(sample1.getId(), analysisId);

EDIT Eh bien, @DavidWallace m’a corrigé, alors soyez prévenu (ou plutôt éclairé) du fait que depuis 1.9 vous pouvez simplement fournir la classe d’exception à lancer et qu’elle en construira une pour vous.

Dans mon cas, au lieu de

 doThrow(exception).when(mock).someVoidMethod()

était

 doThrow(exception).when(mock.someVoidMethod())