mockito
Najlepsze praktyki Mockito

Styl BDDMockito

Styl testowania Behawior Driven Development (BDD) obraca się wokół etapów testów „podanych”, „kiedy” i „wtedy”. Jednak klasyczny Mockito używa fazy „słowo” dla „danej” i nie obejmuje innych konstrukcji języka naturalnego, które mogą obejmować BDD. Tak więc aliasy BDDMockito zostały wprowadzone w wersji 1.8.0 w celu ułatwienia testów opartych na zachowaniu.

Najczęstszą sytuacją jest kasowanie zwrotów metody. W poniższym przykładzie getStudent(String) Sposób wyśmiewali StudentRepository powróci new Student(givenName, givenScore) Po wywołaniu z argumentem, który jest równy 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);
    }
}

Czasami pożądane jest sprawdzenie, czy wyjątek zgłoszony z zależności jest poprawnie obsługiwany lub ponownie zgłaszany w testowanej metodzie. Takie zachowanie można zablokować w „danej” fazie w następujący sposób:

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

Czasami pożądane jest ustalenie niektórych skutków ubocznych, które powinna wprowadzić metoda pośrednicząca. Szczególnie może się przydać, gdy:

• Metoda podstawiona to metoda, która ma zmienić wewnętrzny stan przekazywanego obiektu

• metoda kikuta jest metodą nieważną

Takie zachowanie można ukryć w „danej” fazie za pomocą „odpowiedzi”:

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

Gdy pożądane jest sprawdzenie interakcji z próbą, można to zrobić w fazie „następnie” za pomocą metod should() lub should(VerificationMode) (tylko od 1.10.5):

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

Jeśli pożądane jest sprawdzenie, czy nie było już żadnych interakcji z próbą, poza już zweryfikowanym, można to zrobić w fazie „wtedy” za pomocą funkcji shouldHaveNoMoreInteractions() (od wersji 2.0.0):

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

Gdy trzeba sprawdzić, czy absolutnie nie było interakcji z próbą, można to zrobić w fazie „następnie” za pomocą shouldHaveNoMoreInteractions() (od wersji 2.0.0):

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

Gdy trzeba sprawdzić, czy metody zostały wywołane w kolejności , można to zrobić w fazie „następnie” za pomocą should(InOrder) (od 1.10.5) i should(InOrder, VerificationMode) (od 2.0.0):

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