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