Уже написано много хороших проектов, которые помогут нам упростить использование фиктивных объектов в наших проектах Java. В этой серии статей мы подробно рассмотрим три наиболее широко используемых макетных фреймворка: EasyMock, JMock и Mockito. Мы заканчиваем серию Mockito.
1. Использование Мокито
Мы умеем работать с EasyMock и JMock. Давайте представим фреймворк Mockito (https://site.mockito.org/), еще один популярный фреймворк для имитации.
Для работы с Mockito нужно добавить в файл pom.xml зависимость из листинга 1:
В листинге 2 представлен очень простой объект Account с двумя свойствами: идентификатором учетной записи и балансом.
В листинге 3 показан интерфейс AccountManager, который управляет жизненным циклом и сохранением объектов Account (ограничено поиском учетных записей по идентификатору и обновлением учетных записей):
В листинге 4 показан метод Transfer, предназначенный для перевода денег между двумя счетами. Он использует ранее определенный интерфейс AccountManager для поиска дебетовых и кредитных счетов по идентификатору и их обновления.
Мы хотим иметь возможность модульного тестирования поведения AccountService.transfer . С этой целью, пока реализация интерфейса AccountManager не будет готова, мы будем использовать фиктивную реализацию интерфейса AccountManager, поскольку метод передачи использует этот интерфейс, и нам нужно чтобы проверить его в изоляции.
Пытаясь представить Mockito, мы создаем тест TestAccountService с помощью Mockito, как в листинге 5.
В листинге делаем следующее:
- Как обычно начинаем листинг с импорта всех нужных нам объектов (1). В этом примере с использованием фреймворка Mockito не используются статические функции импорта.
- Мы расширяем этот тест, используя MockitoExtension (2). @ExtendWith — это повторяющаяся аннотация, которая используется для регистрации расширений для аннотированного тестового класса или тестового метода. Для этого примера Mockito мы только отметим, что это расширение необходимо для создания фиктивных объектов с помощью аннотаций, как мы делаем в (3). Это говорит Mockito создать фиктивный объект типа AccountManager.
- Как и в любом из предыдущих списков, мы объявляем два счета, которые мы будем использовать для перевода денег между ними (4).
- В (5) мы начинаем объявлять ожидания, используя метод when. Кроме того, мы используем метод мягкий, чтобы изменить строгость насмешек над объектами. Без него для одного и того же метода findAccountForUser допускается только одно объявление ожидания, но нам нужно два (одно для аргумента «1» и одно для аргумента «2»).
- В (6) начинаем перевод с одного счета на другой, после чего утверждаем ожидаемые результаты (7).
Фрагмент кода из листинга 6 открывает HTTP-соединение с заданным URL-адресом и считывает содержимое по этому URL-адресу. Предположим, что этот код является одним из методов более крупного приложения, которое вы хотите протестировать.
В этом списке:
- Мы открываем HTTP-соединение (1).
- Читаем весь контент, который получен (2).
- Если возникает ошибка, мы возвращаем null (3).
Мы хотим протестировать метод getContent в WebClient. Для этого нам нужно имитировать все зависимости от этого метода. В этом примере у нас есть две зависимости: одна — это ConnectionFactory, а другая — InputStream. Следуя шаблону с EasyMock и JMock, давайте попробуем показать тест WebClient, на этот раз с помощью Mockito.
Заинтересованы в JUnit? Посетите наши тренинги.
Каталин Тудоуз
Эксперт по Java и веб-технологиям
Первоначально опубликовано на https://www.luxoft-training.com.