Вторая часть нашей статьи о тестировании приложений с помощью JUnit5 и JMock. Проверьте это.

Представляем Jmock
Пытаясь представить JMock, мы создаем тест TestAccountService с использованием JMock, как показано в листинге 5.

В листинге делаем следующее:

  1. Как всегда начинаем листинг с импорта всех нужных нам объектов (1). Как видите, в отличие от EasyMock, фреймворк JMock не использует какие-либо функции статического импорта.
  2. JUnit5 предоставляет программный способ регистрации расширений. Для JMock это делается путем аннотации нечастного поля экземпляра JUnit5Mockery с помощью @RegisterExtension. Объект context служит нам для создания макетов и определения ожиданий (2).
  3. В (3) мы объявляем AccountManager, который мы хотим имитировать. Как и EasyMock, основной фреймворк JMock имитирует только интерфейсы.
  4. В методе @BeforeEach, который выполняется перед каждым из методов @Test, мы программно создаем макет с помощью объекта context ( 4).
  5. Как и в любом из предыдущих списков, мы объявляем два счета, которые мы будем использовать для перевода денег между ними (5).
  6. В (6) мы начинаем объявлять ожидания, создавая новый объект Expectations.
  7. В (7) мы объявляем первое ожидание, каждое ожидание имеет вид:

Все пункты необязательны, кроме выделенных жирным шрифтом — invocation-count и mock-object. Нам нужно указать, сколько вызовов будет происходить и для какого объекта. После этого, если метод возвращает объект, мы можем объявить возвращаемый объект с помощью конструкции will(returnValue()).

Следуя этому:

В (8) начинаем перевод с одного счета на другой, после чего утверждаем ожидаемые результаты (9). Это так просто!

Но подождите, что случилось с проверкой количества вызовов? Во всех предыдущих примерах нам нужно было проверить, что вызовы ожиданий произошли ожидаемое количество раз. С JMock вам не нужно этого делать — расширение JMock позаботится об этом, и если какой-либо из ожидаемых вызовов не будет выполнен, тест завершится неудачно.

Фрагмент кода из листинга 6 открывает HTTP-соединение с заданным URL-адресом и считывает содержимое по этому URL-адресу. Предположим, что этот код является одним из методов более крупного приложения, которое вы хотите протестировать.

В этом списке:

  • Открываем HTTP-соединение (1)
  • Читаем весь полученный контент (2)
  • Если возникает ошибка, мы возвращаем null (3)

Мы хотим протестировать метод getContent в WebClient. Для этого нам нужно имитировать все зависимости от этого метода. В этом примере у нас есть две зависимости: одна — это ConnectionFactory, а другая — InputStream. Следуя шаблону с EasyMock, давайте попробуем показать тест WebClient, на этот раз с использованием JMock.

В листинге 7 делаем следующее:

  1. Мы начинаем тестовый пример, регистрируя расширение JMock. Нечастное поле экземпляра JUnit5Mockery context снабжено аннотацией @RegisterExtension (1).
  2. Чтобы указать JMock создавать фиктивные объекты не только для интерфейсов, но и для классов, нам нужно установить свойство imposteriser контекста (2). Теперь мы можем продолжить создавать макеты обычным способом.
  3. В (3) мы объявляем и программно инициализируем два объекта, для которых хотим создать макеты.
  4. В (4) мы начинаем декларацию ожиданий. Обратите внимание, как прекрасно мы объявляем последовательное выполнение метода read() потока (5), а также возвращаемые значения.
  5. В (6) мы вызываем тестируемый метод, а в (7) утверждаем ожидаемый результат.
  6. Чтобы получить полное представление о том, как использовать библиотеку имитации JMock, мы также предоставляем еще один метод @Test, который тестирует наш WebClient в исключительных условиях. В (8) мы объявляем ожидание срабатывания метода close(), а в (9) мы инструктируем JMock вызывать IOException, когда этот триггер происходит.

Выводы

В этой статье продемонстрированы шаги, необходимые для тестирования приложения Java с помощью JUnit 5 и JMock. Мы показали, как тестировать функциональность AccountService, имитируя AccountManager, и WebClient, имитируя ConnectionFactory. и InputStream.

Как видите, библиотека JMock так же проста в использовании, как и EasyMock, но обеспечивает лучшую интеграцию с JUnit 5 — мы можем программно зарегистрировать поле Mockery context. Нам все еще нужно взглянуть на третий предложенный фреймворк: Mockito. Мы увидим, что это ближе к парадигме JUnit 5!

Первоначально опубликовано на https://www.luxoft-training.com.