2014-06-24 21 views
5

Ich experimentiere mit verwenden JMock einige meiner Unit-Tests Umwandlung zu Mockito verwenden und ein paar Stolpersteine ​​getroffen.Mockito vs JMock

zunächst in meinen Tests bei JMock die Verifizierung unter Verwendung von und der Rückkehr des Stutzens in einem Schritt geschehen, wie

folgt
contextMockery.checking(new Expectations() {{ 
     oneOf(dateUtilityService).isBeforeToday(URGENT_DATE); 
      will(returnValue(true)); 
    }}); 

Dies bestätigt, im Wesentlichen, dass die Methode aufgerufen wird, und gibt einen gekapselten Wert bei gleichzeitig. Der Test schlägt fehl, wenn die isBeforeToday-Methode NICHT aufgerufen wird, und gibt gleichzeitig meinen vordefinierten Wert von true zurück. Während bei Mockito Verwendung muß ich überprüfen, ob die Methode aufgerufen wird, und dann meine Dosen Wert in getrennten Schritten zurück, die so ziemlich ein Duplikat ist wie folgt:

doReturn(true).when(dateUtilityService).isBeforeToday(URGENT_DATE); 
    verify(dateUtilityService).isBeforeToday(URGENT_DATE); 

Gibt es keine Möglichkeit, dies in einem Schritt zu tun?

Zweitens, wenn ich vergessen habe, einen Methodenaufruf zu einem meiner Mocks in meinen Erwartungen aufzulisten, scheitert JMock den Test mit "Unerwarteter Aufruf Ausnahme" die meiner Meinung nach richtig ist, während Mockito den Test glücklich bestehen wird, wenn ich nicht explizit verifiziere dass ein Methodenaufruf zum Mock nie passieren darf, ist das richtig (scheint falsch)? Gibt es eine Möglichkeit, Mockito zu sagen, dass der Test fehlschlägt, wenn unerwartete Methodenaufrufe zu meinen verspotteten Abhängigkeiten gemacht werden?

+0

Nur aus Neugier, haben Sie auch prüfen, um die Tests zu JMockit Umwandlung? Die Syntax ist viel näher an jMock: 'new Expectations() {{dateUtilityService.isBeforeToday (URGENT_DATE); Ergebnis = wahr; }}; '. –

Antwort

5

1.

Wenn Sie Stummel ein Verfahren das überprüfen nennen Verfahren in der Regel nicht erforderlich ist - sollten Sie die Aktion überprüfen Sie auf der Rückgabewert basiert (in Ihrem Fall etwas passieren könnte, oder wird etwas zurückgegeben werden, wenn die dateUtilityService zurückkehrt true - überprüfen, dass stattdessen die Interaktion mit einem mock verifizieren

Mockito Dokumentation auch dies spricht über http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html#2

2.

Dies führt tatsächlich zu.. zerbrechliche Tests und ist nicht zu empfehlen, mit Mockito zu tun. Deshalb gibt es keine Möglichkeit, dieses Verhalten festzulegen.

Siehe http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html#8

+0

Das macht in einigen Fällen Sinn (wie die, die ich zeigte), wenn der Stub einen Wert auf Ihrem Rückgabetyp ändert. Aber wie ich in meinem zweiten Teil meiner Frage erwähnt habe, würde ich gerne etwas darüber wissen, wenn ich einen Methodenaufruf stubbe (der keinen Rückgabewert ändern kann), damit ich eine bewusste Entscheidung treffen kann Stoppen Sie den Anruf oder sagen Sie dem Test, dass er nie angerufen werden sollte. –

+1

@ClintonBosch Sie einen Anruf zu 'verifyNoMoreInteractions hinzufügen können()' am Ende des Testverfahrens, alle unstubbed Anrufe zu erkennen. –

+0

Seit ich Mockito verwenden (I verwendet JMock seit 2007 oder sogar vor ... Ich erinnere mich nicht), bemerkte ich, grün Tests, bei denen Kollegen die Mitarbeiter zu nennen vergessen, hörte ich Sätze wie „Unit-Tests Sie irgendwann zu falsch positiven , es ist besser, Integrationstests zu haben ". Vielleicht ist es besser, ein Werkzeug wie JMock zu verwenden und zu versuchen, diese "zerbrechlichen Tests" auf eine andere Weise zu vermeiden, anstatt so schwache Designwerkzeuge wie Mockito zu verwenden. – sixro