Поиск…


Стиль BDDMockito

Стиль тестирования, управляемый поведением (BDD), вращается вокруг «заданных», «когда» и «затем» этапов в тестах. Однако классический Mockito использует слово «когда» для «заданной» фазы и не включает в себя другие конструкции естественного языка, которые могут охватывать BDD. Таким образом, псевдонимы BDDMockito были введены в версии 1.8.0, чтобы облегчить тесты, управляемые поведением.

Наиболее распространенной ситуацией является заглушка возврата метода. В следующем примере getStudent(String) StudentRepository вернет new Student(givenName, givenScore) если он вызван с аргументом, равным 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);
    }
}

Иногда бывает необходимо проверить, правильно ли обработано или отвернуто исключение, вызванное зависимостью, в тестируемом методе. Такое поведение может быть заострено в «заданной» фазе таким образом:

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

Иногда желательно установить некоторые побочные эффекты, которые должен вводить метод с заглублением. Особенно это может пригодиться, когда:

  • заштрихованный метод - это метод, который должен изменить внутреннее состояние переданного объекта

  • пропущенный метод является недействительным методом

Такое поведение можно окутать в «заданную» фазу с помощью «Ответ»:

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

Когда требуется проверить взаимодействия с макетом, это можно сделать в фазе «then» с помощью методов to should() или should(VerificationMode) (только с 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

Когда необходимо проверить, что больше не было взаимодействий с макетом, кроме уже проверенных, это можно сделать на «затем» фазе с shouldHaveNoMoreInteractions() (начиная с 2.0.0):

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

Когда необходимо проверить, что взаимодействия с shouldHaveNoMoreInteractions() не было абсолютно, это можно сделать на «затем» фазе с shouldHaveNoMoreInteractions() (начиная с 2.0.0):

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

Когда нужно проверить, были ли методы вызваны, чтобы их можно было выполнить в фазе «затем» с помощью should(InOrder) (с 1.10.5) и should(InOrder, VerificationMode) (начиная с 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


Modified text is an extract of the original Stack Overflow Documentation
Лицензировано согласно CC BY-SA 3.0
Не связан с Stack Overflow