Уже написано много хороших проектов, которые помогут нам упростить использование фиктивных объектов в наших проектах 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. Как обычно начинаем листинг с импорта всех нужных нам объектов (1). В этом примере с использованием фреймворка Mockito не используются статические функции импорта.
  2. Мы расширяем этот тест, используя MockitoExtension (2). @ExtendWith — это повторяющаяся аннотация, которая используется для регистрации расширений для аннотированного тестового класса или тестового метода. Для этого примера Mockito мы только отметим, что это расширение необходимо для создания фиктивных объектов с помощью аннотаций, как мы делаем в (3). Это говорит Mockito создать фиктивный объект типа AccountManager.
  3. Как и в любом из предыдущих списков, мы объявляем два счета, которые мы будем использовать для перевода денег между ними (4).
  4. В (5) мы начинаем объявлять ожидания, используя метод when. Кроме того, мы используем метод мягкий, чтобы изменить строгость насмешек над объектами. Без него для одного и того же метода findAccountForUser допускается только одно объявление ожидания, но нам нужно два (одно для аргумента «1» и одно для аргумента «2»).
  5. В (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.