Home » Примеры моков Mockito — юнит-тестирование в Java

Примеры моков Mockito — юнит-тестирование в Java

Когда дело доходит до юнит-тестирования в Java, Mockito становится настоящим спасением для разработчиков. Если вы админите сервера и настраиваете CI/CD пайплайны, то автоматизированное тестирование — это не просто nice-to-have, а must-have для стабильности ваших проектов. Эта статья покажет практические примеры использования Mockito для создания эффективных юнит-тестов, которые помогут вам ловить баги до того, как они попадут в продакшн. Мы разберём как быстро настроить моки, посмотрим на реальные кейсы и научимся автоматизировать тестирование в ваших Java-приложениях.

Как работает Mockito — основы для понимания

Mockito — это Java-фреймворк для создания mock-объектов в юнит-тестах. Проще говоря, он позволяет создавать “поддельные” объекты, которые имитируют поведение реальных зависимостей. Зачем это нужно? Представьте, что вы тестируете сервис, который обращается к базе данных или внешнему API. Вместо того чтобы поднимать реальную БД для каждого теста, мы создаём мок, который возвращает нужные нам данные.

Основные принципы работы:

Создание мока — Mockito создаёт proxy-объект, который перехватывает вызовы методов
Stubbing — настройка поведения мока (что должен возвращать метод)
Verification — проверка того, что определённые методы были вызваны
Argument matching — гибкая настройка параметров для методов

Быстрая настройка Mockito — шаг за шагом

Для начала работы добавляем зависимость в pom.xml:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>5.7.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>5.7.0</version>
    <scope>test</scope>
</dependency>

Базовая настройка тестового класса:

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.InjectMocks;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
class UserServiceTest {
    
    @Mock
    private UserRepository userRepository;
    
    @InjectMocks
    private UserService userService;
    
    @Test
    void shouldReturnUserById() {
        // тест код
    }
}

Практические примеры и кейсы

Пример 1: Мокирование репозитория

Классический случай — тестирование сервиса, который работает с базой данных:

@Test
void shouldReturnUserWhenValidId() {
    // Given
    Long userId = 1L;
    User expectedUser = new User(userId, "John", "john@example.com");
    when(userRepository.findById(userId)).thenReturn(Optional.of(expectedUser));
    
    // When
    User result = userService.getUserById(userId);
    
    // Then
    assertThat(result).isEqualTo(expectedUser);
    verify(userRepository).findById(userId);
}

Пример 2: Мокирование внешних сервисов

Когда ваш сервис интегрируется с внешним API:

@Test
void shouldSendNotificationWhenUserCreated() {
    // Given
    User newUser = new User("Jane", "jane@example.com");
    when(userRepository.save(any(User.class))).thenReturn(newUser);
    
    // When
    userService.createUser(newUser);
    
    // Then
    verify(notificationService).sendWelcomeEmail(newUser.getEmail());
    verify(userRepository).save(newUser);
}

Пример 3: Тестирование исключений

Проверяем, как приложение обрабатывает ошибки:

@Test
void shouldThrowExceptionWhenUserNotFound() {
    // Given
    Long userId = 999L;
    when(userRepository.findById(userId)).thenReturn(Optional.empty());
    
    // When/Then
    assertThatThrownBy(() -> userService.getUserById(userId))
        .isInstanceOf(UserNotFoundException.class)
        .hasMessage("User with id 999 not found");
}

Продвинутые техники и трюки

Argument Matchers

Для более гибкого тестирования используем argument matchers:

// Любой объект типа User
when(userRepository.save(any(User.class))).thenReturn(savedUser);

// Строка, содержащая определённый текст
when(emailService.sendEmail(contains("@admin.com"))).thenReturn(true);

// Кастомный matcher
when(userRepository.findByAge(argThat(age -> age >= 18))).thenReturn(adultUsers);

Spy объекты

Когда нужно замокать только часть методов реального объекта:

@Test
void shouldUseSpyForPartialMocking() {
    // Given
    UserService userServiceSpy = spy(userService);
    doReturn(true).when(userServiceSpy).isEmailUnique("test@example.com");
    
    // When
    boolean result = userServiceSpy.validateUser(newUser);
    
    // Then
    assertThat(result).isTrue();
}

Сравнение с альтернативами

Фреймворк	Плюсы	Минусы	Лучше использовать для
Mockito	Простота использования, богатая функциональность, активное сообщество	Не работает с static методами (в старых версиях), требует дополнительных настроек для final классов	Стандартные Java-приложения, Spring Boot
PowerMock	Работает со static методами, final классами, private методами	Медленнее, сложнее в настройке, менее стабильный	Legacy код, сложные сценарии мокирования
EasyMock	Простой синтаксис, меньше magic	Менее функциональный, меньше community support	Простые тесты, когда нужен минимализм

Автоматизация и интеграция с CI/CD

Для автоматизации тестирования на серверах создаём Maven профиль:

<profile>
    <id>test-coverage</id>
    <build>
        <plugins>
            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.8.8</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>report</id>
                        <phase>test</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

Скрипт для Jenkins или GitLab CI:

#!/bin/bash
# Запуск тестов с покрытием
mvn clean test -Ptest-coverage

# Проверка минимального покрытия
if [ $(grep -o "instruction-covered.*" target/site/jacoco/index.html | grep -o "[0-9]\+") -lt 80 ]; then
    echo "Test coverage below 80%"
    exit 1
fi

echo "All tests passed with sufficient coverage"

Нестандартные применения и интересные факты

Mockito можно использовать не только для классических юнит-тестов:

Тестирование производительности — создавать моки, которые эмулируют медленные операции
Симуляция нагрузки — использовать моки для тестирования поведения под высокой нагрузкой
A/B тестирование — моки могут возвращать разные результаты для тестирования различных сценариев
Тестирование безопасности — эмулировать различные роли и права доступа

Интересный факт: Mockito был создан в 2007 году польским разработчиком Щепаном Фабером (Szczepan Faber) и получил название от испанского коктейля “Мохито”. Фреймворк стал настолько популярным, что Google включил его в Android SDK.

Лучшие практики и рекомендации

Не злоупотребляйте моками — если тест требует слишком много моков, возможно, стоит пересмотреть архитектуру
Используйте @Mock вместо mock() — это делает код чище и понятнее
Всегда проверяйте взаимодействия — используйте verify() для проверки вызовов методов
Изолируйте тесты — каждый тест должен быть независимым от других
Тестируйте граничные случаи — особенно важно для серверных приложений

Для разработки и тестирования серверных приложений рекомендую использовать VPS-сервер с достаточным объёмом RAM для запуска тестов. Если проект крупный и требует ресурсов для CI/CD, стоит рассмотреть выделенный сервер.

Заключение и рекомендации

Mockito — это мощный инструмент, который должен быть в арсенале каждого Java-разработчика. Он позволяет создавать быстрые, надёжные и изолированные тесты, что критически важно для поддержания качества кода в долгосрочной перспективе. Особенно это актуально для серверных приложений, где цена ошибки может быть очень высокой.

Основные рекомендации:

Начинайте с простых моков и постепенно изучайте продвинутые возможности
Интегрируйте тестирование в CI/CD пайплайн с самого начала проекта
Стремитесь к покрытию кода тестами не менее 80%
Используйте моки для изоляции внешних зависимостей
Регулярно рефакторите тесты вместе с продакшн-кодом

Mockito отлично подходит для тестирования REST API, микросервисов, интеграций с базами данных и внешними сервисами. В связке с Spring Boot Test и TestContainers он создаёт мощную экосистему для комплексного тестирования приложений.

Официальная документация доступна по адресу: https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html

В этой статье собрана информация и материалы из различных интернет-источников. Мы признаем и ценим работу всех оригинальных авторов, издателей и веб-сайтов. Несмотря на то, что были приложены все усилия для надлежащего указания исходного материала, любая непреднамеренная оплошность или упущение не являются нарушением авторских прав. Все упомянутые товарные знаки, логотипы и изображения являются собственностью соответствующих владельцев. Если вы считаете, что какой-либо контент, использованный в этой статье, нарушает ваши авторские права, немедленно свяжитесь с нами для рассмотрения и принятия оперативных мер.

Данная статья предназначена исключительно для ознакомительных и образовательных целей и не ущемляет права правообладателей. Если какой-либо материал, защищенный авторским правом, был использован без должного упоминания или с нарушением законов об авторском праве, это непреднамеренно, и мы исправим это незамедлительно после уведомления. Обратите внимание, что переиздание, распространение или воспроизведение части или всего содержимого в любой форме запрещено без письменного разрешения автора и владельца веб-сайта. Для получения разрешений или дополнительных запросов, пожалуйста, свяжитесь с нами.