mockito
Mockito Best Practices

BDDMockito-Stil

BDD-Teststile (Behavior Driven Development) beziehen sich auf die Stufen "vorgegeben", "wann" und "dann" in Tests. Das klassische Mockito verwendet jedoch "when" als Wort für "gegebene" Phase und schließt keine anderen Konstruktionen in natürlicher Sprache ein, die BDD umfassen können. Daher wurden in Version 1.8.0 BDDMockito- Aliase eingeführt, um verhaltensabhängige Tests zu erleichtern.

Die häufigste Situation ist das Stub-Return einer Methode. Im folgenden Beispiel gibt die getStudent(String) -Methode des getStudent(String) StudentRepository einen new Student(givenName, givenScore) wenn er mit einem Argument aufgerufen wird, das gleich givenName .

import static org.mockito.BDDMockito.*;

public class ScoreServiceTest {

    private StudentRepository studentRepository = mock(StudentRepository.class);

    private ScoreService objectUnderTest = new ScoreService(studentRepository);

    @Test
    public void shouldCalculateAndReturnScore() throws Exception {
        //given
        String givenName = "Johnny";
        int givenScore = 10;
        given(studentRepository.getStudent(givenName))
            .willReturn(new Student(givenName, givenScore));

        //when
        String actualScore = objectUnderTest.calculateStudentScore(givenName);

        //then
        assertEquals(givenScore, actualScore);
    }
}

Manchmal ist es wünschenswert zu prüfen, ob eine aus der Abhängigkeit geworfene Ausnahme in einer zu testenden Methode korrekt behandelt oder erneut ausgegeben wird. Ein solches Verhalten kann auf diese Weise in der "gegebenen" Phase abgebrochen werden:

willThrow(new RuntimeException())).given(mock).getData();

Manchmal ist es wünschenswert, einige Nebenwirkungen einzustellen, die eine Stubbed-Methode einführen soll. Besonders nützlich kann es sein, wenn:

• Die Stubbed-Methode ist eine Methode, die den internen Status eines übergebenen Objekts ändern soll

• Die Stubbed-Methode ist eine Void-Methode

Ein solches Verhalten kann in einer "gegebenen" Phase mit einer "Antwort" belegt werden:

willAnswer(invocation -> this.prepareData(invocation.getArguments()[0])).given(mock).processData();

Wenn Interaktionen mit einem Mock verifiziert werden sollen, kann dies in der "then" -Phase mit den Methoden should() oder should(VerificationMode) (nur seit 1.10.5) erfolgen:

then(mock).should().getData(); // verifies that getData() was called once
then(mock).should(times(2)).processData(); // verifies that processData() was called twice

Wenn Sie nachweisen möchten, dass keine Interaktionen mit einem Mock mehr vorhanden sind, als bereits verifiziert, kann dies in der "dann" -Phase mit shouldHaveNoMoreInteractions() (seit 2.0.0) erfolgen:

then(mock).shouldHaveNoMoreInteractions(); // analogue of verifyNoMoreInteractions(mock) in classical Mockito

Wenn Sie shouldHaveNoMoreInteractions() , dass absolut keine Interaktionen mit einem Mock shouldHaveNoMoreInteractions() , kann dies in der "dann" -Phase mit shouldHaveNoMoreInteractions() (seit 2.0.0) erfolgen:

then(mock).shouldHaveZeroInteractions(); // analogue of verifyZeroInteractions(mock) in classical Mockito

Wenn gewünscht wird, zu prüfen, ob Methoden aufgerufen wurden, kann dies in der "dann" -Phase mit should(InOrder) (seit 1.10.5) und should(InOrder, VerificationMode) (seit 2.0.0) erfolgen:

InOrder inOrder = inOrder(mock);

// test body here

then(mock).should(inOrder).getData(); // the first invocation on the mock should be getData() invocation
then(mock).should(inOrder, times(2)).processData(); // the second and third invocations on the mock should be processData() invocations