Меня зовут Игорь Симаков, я тимлид Java-разработки в команде Маркетплейс Банки.ру. Сегодня на практическом примере разберу использование UNIT-тестирования. Оно применяется как для тестирования состояния, так и для проверки поведения кода. В этом материале сосредоточусь на последнем аспекте. Покажу, как использовать JUnit, Mockito и AssertJ для тестирования кода, а также JaCoCo для оценки покрытия тестами на примере простого мини-сервиса.
Эта статья основана на моем внутреннем воркшопе, который я проводил для своих коллег. В моем репозитории можно ознакомиться с текстом доклада. Там содержится обзор основных понятий, используемых в статье, а также подробное описание инструментов.
Сервис для примера
Для наглядной демонстрации инструментов UNIT-тестирования я разработал сервис, который получает прогноз погоды по городам.
Бизнес-логика несложная: сервис выбирает из рандома 50, 100 и 150 городов, отправляет запросы, получает данные в формате englishname и ключ, и затем получает погодные условия по этому ключу. Код сервиса доступен на GitHub.
@RequiredArgsConstructor
public class AccuweatherService {
private final AccuweatherClient accuweatherClient;
private final EventService eventService;
public void checkAccuweather() {
Stream.of(50, 100, 150)
.findAny()
.map(TopCitiesCount::findByValue)
.map(this::getTopCityLocation)
.map(this::getCurrentConditionByLocation)
.ifPresent(eventService::sendEvent);
}
public CurrentCondition getCurrentConditionByLocation(
final LocationRoot locationRoot) {
return Arrays.stream(
accuweatherClient.getCurrentConditionsByLocationKey(
locationRoot.getKey()))
.findFirst()
.orElseThrow();
}
public LocationRoot getTopCityLocation(final TopCitiesCount citiesCount) {
return Arrays.stream(accuweatherClient.getTopcities(citiesCount))
.findAny()
.orElseThrow();
}
public void callWithException() {
throw new ServiceException("Smthing go wrong!", null);
}
}Итак, у нас есть рабочий код, и теперь я хочу покрыть его тестами. Как это сделать? Для этого я буду использовать четыре основных инструмента:
Основные инструменты тестирования
JUnit. фреймворк для тестирования Java-приложений. Предоставляет аннотации и классы для определения и запуска тестов, а также для проверки ожидаемых результатов. JUnit значительно облегчает создание и выполнение тестовых сценариев.
Mockito. Библиотека для создания моков (фиктивных объектов) в тестах. Позволяет настроить поведение моков и проверить, как взаимодействует тестируемый код с этими моками.
AssertJ. Библиотека для создания утверждений в тестах. Предоставляет более выразительные методы для проверки ожидаемых результатов, что делает тесты более читаемыми и понятными.
JaCoCo (Java Code Coverage). Инструмент, который измеряет покрытие кода тестами. Анализирует выполнение тестов и предоставляет отчеты о покрытии, позволяя определить, какие части кода были протестированы, а какие — нет. JaCoCo помогает локализовать недостаточно протестированные участки кода и повышает качество тестирования.
В примерах тестов я буду комбинировать все эти инструменты.
Анализируем покрытие кода тестами JaCoCo
Предположим, мы приняли гипотетический сервис на поддержку и при этом практически не знакомы с кодовой базой. Нужно определить, какие куски кода стоит покрыть тестами. Для этого я использую JaCoCo. В JaCoCo несколько видов покрытия. Можно оценить, какой процент строк кода и ветвей был покрыт тестами, покрытие инструкций, методов и классов. Каждый вид покрытия можно настроить, указать минимальный порог, который будет использован при сборке.
Итак, я подключаю и настраиваю плагин JaCoCo: могу исключить из проверки пакеты, которые не хочу покрывать тестами. Например, покрытие модели данных. Также указываю минимальный порог тестирования, ниже которого сборка не пройдет.
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<configuration>
<excludes>
<exclude>ru/example/com/model/**/*</exclude>
<exclude>ru/example/com/client/*</exclude>
<exclude>ru/example/com/utils/*</exclude>
</excludes>
</configuration>
<executions>
<execution>
<id>prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>check-minimal</id>
<phase>package</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<rules>
<rule>
<element>BUNDLE</element>
<limits>
<limit>
<counter>INSTRUCTION</counter>
<value>COVEREDRATIO</value>
<minimum>1.0</minimum> <!-- вот тут -->
</limit>
<limit>
<counter>BRANCH</counter>
<value>COVEREDRATIO</value>
<minimum>1.0</minimum> <!-- и тут -->
</limit>
<limit>
<counter>CLASS</counter>
<value>MISSEDCOUNT</value>
<maximum>0</maximum> <!-- и тут -->
</limit>
<limit>
<counter>METHOD</counter>
<value>MISSEDCOUNT</value>
<maximum>0</maximum> <!-- и тут -->
</limit>
<limit>
<counter>LINE</counter>
<value>MISSEDCOUNT</value>
<maximum>0</maximum> <!-- и тут -->
</limit>
</limits>
</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>
Запускаю сборку своего сервиса, прогоняю тесты и вижу, что сборка падает: три класса не покрыты по строкам и по методам.
В результате проверки JaCoCo отдает HTMLку (можно найти в target/site/jacoco/index.html). Захожу на сервисный слой, где есть разбивка по методам, и вижу, что ни один из них не покрыт. Значит, нужно заняться тестированием, чтобы достичь минимального порога.
Приступаем к тестированию
Создаем моки и спай с помощью Mockito
В Mockito есть несколько типов объектов для тестирования:
Mock — это фиктивный объект, который можно настроить так, чтобы он возвращал определенные значения из вызовов методов. Например, у нас есть класс с методами A, B и C. Мы хотим протестировать метод A, при этом вызовы методов B и C не должны выполняться. Чтобы «заглушить» вызовы B и C и вернуть заданный результат, используем mock.
Spy — это полностью функционирующий объект. Если нам нужно проверить, вызывался ли метод B из метода A, используем spy. Spy позволяет отслеживать вызовы всех методов объекта и проверять их.
В моем примере я полностью мокирую клиент AccuweatherClient, а для eventService использую аннотацию @Spy . Мне нужно убедиться, что он был вызван с ожидаемыми параметрами. Также я использую аннотацию @InejctMocks для внедрения зависимостей в сервис и @ExtendWith, чтобы все заработало.
@ExtendWith(MockitoExtension.class)
class AccuweatherServiceTest {
@Mock
private AccuweatherClient accuweatherClient;
@Spy
private EventService eventService;
@InjectMocks
private AccuweatherService accuweatherService;Тестируем getСurrentСonditionByLocation с помощью Mockito.when и Mockito.thenReturn
Метод getCurrentConditionByLocation принимает объект LocationRoot, вызывает метод accuweatherClient.getCurrentConditionByLocationKey() и возвращает первый попавшийся элемент. Если ничего не найдено — выбрасывает исключение.
public CurrentCondition getCurrentConditionByLocation(
final LocationRoot locationRoot) {
return Arrays.stream(accuweatherClient.getCurrentConditionsByLocationKey(
locationRoot.getKey()))
.findFirst()
.orElseThrow();
}Я уже замокал accuweatherClient и теперь хочу определить поведение его методов в тестировании с помощью when() и thenReturn() из библиотеки Mockito.
Структура теста
GIVEN — подготовка тестовых данных.
Когда будет вызываться метод getCurrentConditionByLocation с заданным параметром (в нашем случае это request.getKey), мы будем возвращать currentConditions.
currentConditions — это массив объектов, который я создаю с помощью Mockito.mock(). Мокирую его, потому что его состояние не важно.
WHEN. Вызываем тестируемый метод.
THEN. Используя assertThat() и isEqualTo из библиотеки AssertJ, я проверяю, что полученный результат метода соответствует элементу, который я положил в массив. С помощью Mockito.verify() проверяю, что getCurrentConditionByLockation был вызван ровно один раз с заданным параметром getKey.
@Test
void getCurrentConditionByLocationShouldWork() {
//GIVEN
var currentCondition = Mockito.mock(CurrentCondition.class);
CurrentCondition[] currentConditions = {currentCondition};
var request = DataProvider.prepareLocationRoot().build();
Mockito.when(accuweatherClient.getCurrentConditionsByLocationKey(request.getKey()))
.thenReturn(currentConditions);
//WHEN
var result = accuweatherService.getCurrentConditionByLocation(request);
//THEN
assertThat(result).isEqualTo(currentCondition);
Mockito.verify(accuweatherClient, Mockito.times(1))
.getCurrentConditionsByLocationKey(request.getKey());
}Отдельно про Mockito.verify
В моем примере я замокал метод вызова клиента accuweatherClient, поэтому после вызова проверяющего метода мне нужно убедиться, что accuweatherClient действительно был вызван. Для этого я применил Mockito.verify().
Я также использовал параметр times(), где указал, что метод getCurrentConditionByLocationKey с параметром request.getKey должен быть вызван один раз. Вообще, единицу можно не писать: при использовании times() по умолчанию проверяется именно единичный вызов тестируемого метода.
Можно использовать и другие количественные проверки:
atLeastOnce(),atMostOnes(),atLeast(),atMost(),never().
Как проверить, что вызван только один метод и никакие другие
Еще одна хорошая практика — проверять, чтобы никакие другие методы для этого клиента не были вызваны. Допустим, у нас в методе getCurrentConditionByLocation есть вызов какого-то другого метода. Если прогоним тест и метод выполнится, это будет означать, что кое-что в тестировании мы упустили.
Чтобы такого не происходило, нужно либо провести проверку этого дополнительного метода с использованием Mockito.verify() и убедиться, что он тоже был вызван. Либо применить never(), если хотим удостовериться, что никакого другого метода не было вызвано.
Для этих же целей у Mockito есть verifyNoMoreInteractions(). Используя аннотацию @AfterEach, он будет запускаться после выполнения каждого метода и проверять, что никакие другие методы на наших замокированных зависимостях не были вызваны.
@AfterEach
void afterEach() {
Mockito.verifyNoMoreInteractions(accuweatherClient, eventService);
}Теперь у меня есть полная структура теста с использованием Mockito.verify(), которая поможет убедиться в правильности вызова зависимостей.
После выполнения тестов возвращаюсь к отчету JaCoCo в формате HTML и вижу, что один метод теперь выделен зеленым цветом. Это означает, что я успешно протестировал конструктор и этот метод.
Покрытие кода повысилось, но еще недостаточно: еще есть методы, которые нужно протестировать. Поэтому тестирование продолжаю.
Тестируем метод getTopCityLocation с помощью ParameterizedTest.
Для демонстрации работы параметризованных тестов протестирую метод getTopCityLocation. Этот метод принимает на вход topCityCount — enum из трех элементов: FIFTY, HUNDRED, HUNDRED_FIFTY.
public LocationRoot getTopCityLocation(final TopCitiesCount citiesCount) {
return Arrays.stream(accuweatherClient.getTopcities(citiesCount))
.findAny()
.orElseThrow();
}Мне нужно протестировать каждый из трех элементов, но я не хочу дублировать код тестов. Для таких целей в JUnit есть аннотация @ParameterizedTest. Я также использую @EnumSource, чтобы указать enum, из которого хочу перебрать элементы. Если мне нужно исключить один или несколько элементов из тестирования, буду использовать EnumSource.Mode.EXCLUDE. В своем тесте применю его к элементу FIFTY.
@ParameterizedTest
@EnumSource(
value = TopCitiesCount.class,
mode = EnumSource.Mode.EXCLUDE,
names = {"FIFTY"}
)
void getTopCityLocationShouldWork(final TopCitiesCount topCitiesCount) {
//GIVEN
var locationRoot = DataProvider.buildLocationRoot().build();
LocationRoot[] locationRoots = {locationRoot};
Mockito.when(accuweatherClient.getTopcities(any(TopCitiesCount.class)))
.thenReturn(locationRoots);
//WHEN
var result = accuweatherService.getTopCityLocation(topCitiesCount);
//THEN
assertThat(result)
.usingRecursiveComparison()
.ignoringFields("englishName")
.isEqualTo(locationRoot);
Mockito.verify(accuweatherClient).getTopcities(topCitiesCount);
}
Метод getTopcities я мокирую с помощью Mockito.when() и использую новую конструкцию — argument matcher. Это механизм, который позволяет гибко определять ожидаемые аргументы при вызове мок-объектов. Argument matcher особенно полезно использовать, когда тестируемый метод ожидает специфические значения аргументов, и вы хотите, чтобы тест был более гибким и устойчивым к изменениям. Если в тесте мне не важно, какой будет параметр — главное, чтобы он был — я использую метод any().
AssertJ — usingrecursionComparison
Проверяем полученные значения с помощью метода usingRecursiveComparison() из AssertJ. Он позволяет свойство за свойством сравнивать два объекта, перебирая их и сравнивая с ожидаемым результатом. При этом можно проигнорировать определенные поля, используя команду ignoringFields. Сейчас я решил не сравнивать параметры englishName.
После прогона теста возвращаемся в JaCoCo для проверки. Видим, что второй метод теперь загорается зеленым. Покрытие увеличилось до 42% — стало лучше.
Тестируем callWithExceptions метод с помощью assertThatThrounBy
Для тестирования метода исключений callWithExceptions используем функционал AssertJ: метод assertThatThrounBy, который принимает лямбду.
@Test
void callWithExceptionShouldThrowServiceException() {
Assertions.assertThatThrownBy(() -> accuweatherService.callWithException())
.isInstanceOf(ServiceException.class)
.hasMessageContaining("Smthing go wrong!")
.hasStackTraceContaining(
"ru.simakov.com.service.AccuweatherService. callWithException");
}Что проверяем в исключениях:
класс исключения является инстансом класса
ServiceException—isInstanceOf(ServiceException.class)сообщение, которое появляется при ошибке —
hasMessageContaining("Smthing go wrong!")стек трейс контейнер содержит наш сервис и наш метод —
hasStackTraceContaining("ru.simakov.com.service.AccuweatherService.callWithException")
После запуска возвращаемся в JaCoCO и вновь проверяем покрытие. Поднялось!
Тестируем основной метод chechAccueweather
Этот метод рандомно выбирает 50, 100 или 150 значений, затем получает из них enum с помощью findByValue. После чего вызывает метод getTopCityLocation, затем getCurrentConditionByLocation и отправляет результат в очередь.
public void checkAccuweather() {
Stream.of(50, 100, 150)
.findAny()
.map(TopCitiesCount::findByValue)
.map(this::getTopCityLocation)
.map(this::getCurrentConditionByLocation)
.ifPresent(eventService::sendEvent);
}В тесте будут использоваться два мока клиента accuweatherClient. Первый метод, getTopCities, будет возвращать locationRoots. Второй, getCurrentConditionByLocationKey, — возвращать массив текущих условий (currentCondition).
После вызова checkAccuweather нужно проверить, что методы действительно были вызваны, поэтому я использую Mockito.verify().
Мне неважно, с каким enam-элементом будет вызван gettopCities, поэтому я использую any. А вот getCurrentConditionByLocation будет вызван с объектом из моего мока, из которого должно прийти 1,2,3. Поэтому я ожидаю, что getCurrentConditionByLocation будет вызван один раз именно с этим значением. Как будет выглядеть тест метода
@Test
void checkAccuweatherShouldWork() {
//GIVEN
var locationRoot = DataProvider.buildLocationRoot().build();
LocationRoot[] locationRoots = {locationRoot};
var currentCondition = DataProvider.prepareCurrentConditions();
Mockito.when(accuweatherClient.getTopcities(any(TopCitiesCount.class)))
.thenReturn(locationRoots);
Mockito.when(accuweatherClient.getCurrentConditionsByLocationKey(any()))
.thenReturn(new CurrentCondition[]{currentCondition});
//WHEN
accuweatherService.checkAccuweather();
//THEN
Mockito.verify(accuweatherClient).getTopcities(any());
Mockito.verify(accuweatherClient).getCurrentConditionsByLocationKey("123");
verifySendEvent();
}
ArgumentCaptor для проверки аргументов
В сервисе есть метод sendEvent, который получает объект currentCondition. Я хочу убедиться, что этот метод был вызван один раз, и проверить аргументы, с которыми он был вызван. Но как это сделать, если он ничего не возвращает? Для этого использую ArgumentCaptor — инструмент библиотеки Mockito, который позволяет захватывать и сохранять аргументы, переданные в методе мока.
private void verifySendEvent() {
var captor = ArgumentCaptor.forClass(CurrentCondition.class);
Mockito.verify(eventService).sendEvent(captor.capture());
assertThat(captor.getValue())
.isNotNull()
.satisfies(currentCondition1 -> assertThat(currentCondition1)
.extracting(CurrentCondition::getEpochTime,
CurrentCondition::getWeatherText,
CurrentCondition::isHasPrecipitation)
.containsExactly(123_456_789, "Sunny", false))
.extracting(CurrentCondition::getTemperature)
.extracting(CurrentCondition.Temperature::getImperial,
CurrentCondition.Temperature::getMetric)
.containsExactly(
CurrentCondition.Imperial.builder()
.value(77)
.unit("Fahrenheit")
.unitType(18)
.build(),
CurrentCondition.Metric.builder()
.value(25.0)
.unit("Celsius")
.unitType(17)
.build()
);
}Применяя его, я получу значение, которое будет содержать объект со всеми данными, переданными в метод sendEvent. Если sendEvent был вызван два раза, captor захватит два объекта, вызванных методом.
Теперь я хочу проверить, что в таком объекте getValue не будет равен нулю. Чтобы убедиться в этом, использую метод satisfies, благодаря которому на вытащенном объекте можно запустить цепочку отдельных проверок. Например, в объекте currentCondition есть вложенные объекты epochTime, weatherText, hasPrecipitation. Вместо того чтобы создавать отдельные проверки для всех трех полей, я использую команду extracting и добавляю containsExactly, чтобы внедрить сопоставления для каждого поля.
Это удобно и сокращает количество строк кода. При этом общую цепочку я не нарушил, а просто сделал ответвление.
Итак, я проверил, что в сервисе были вызваны три метода, и что sendEvent был вызван с теми данными, которые мне нужны. Перехожу в JaCoCo, перезапускаю проверку — 100% методов покрыты тестами. Отлично! Напомню, что accuweatherClient я исключил из проверки, потому что его мы тестируем отдельно.
Вывод
Я продемонстрировал принципы и инструменты для написания и тестирования кода в Java с использованием модулей JUnit5, Mockito и AssertJ и проверку покрытия кода тестами с помощью JACoCo. Такой подход к проверке кода мы используем в Банки.ру. За счет чего обеспечиваем хорошее покрытия кода тестами и снижаем вероятность ошибок в продакшене.
Что, нам мой взгляд, важно:
Использовать JaCoCo, чтобы проверить покрытие кода тестами и наглядно видеть, какие методы не были протестированы и что еще не покрыто тестами.
Не забывать проверять, как отрабатывают методы, которые ничего не возвращают
Проверять вызовы других методов на замокированных зависимостях.
