Mocking и Stubbing

Введение: Дублёры в тестировании

Представьте, что вы тестируете систему управления заказами, которая отправляет уведомления в SMS-шлюз. Каждый раз, когда вы запускаете тест, он отправляет реальное SMS. Это дорого, медленно и может разозлить получателей.

Вместо этого вы подменяете SMS-шлюз заглушкой (stub), которая всегда отвечает “успешно”. Или двойником (mock), который запоминает, что его вызывали, и потом вы проверяете: “А точно ли SMS был отправлен?”.

Mocking и Stubbing — это техники создания дублёров для зависимостей при тестировании. Они позволяют тестировать компонент в изоляции, не поднимая реальные базы данных, внешние API, очереди сообщений.

Для системного аналитика эти понятия важны, потому что они определяют, насколько тесты надёжны, быстры и независимы. Вы не пишете эти тесты, но вы оцениваете стратегию тестирования, интерпретируете результаты и понимаете ограничения.

Основные понятия

Stub (Заглушка)

Что это

Stub — это объект, который возвращает заранее заданные ответы на вызовы. Он не проверяет, как его вызвали. Просто возвращает то, что вы настроили.

Когда использовать

Пример из реальности

Без stub (плохо):

Тест создаёт заказ → API вызывает реальный SMS-шлюз → уходит реальное SMS → медленно, дорого, раздражает.

Со stub (хорошо):

Тест создаёт заказ → API вызывает заглушку SMS-шлюза → заглушка мгновенно отвечает “успешно” → быстро, дёшево, никому не звонит.

Что должен знать аналитик

Mock (Двойник)

Что это

Mock — это объект, который запоминает, как его вызывали. После теста вы проверяете: “Был ли вызван метод?”, “С какими параметрами?”, “Сколько раз?”.

Когда использовать

Пример из реальности

Mock:

Тест создаёт пользователя → API вызывает мок-сервис уведомлений → мок запоминает, что его вызвали с email “ivan@example.com”.

После теста проверка: “Был ли вызван метод отправки уведомления?” → Да. “С правильным email?” → Да.

Что должен знать аналитик

Stub vs Mock

Аналогия:

• Stub — кассир, который всегда говорит “билет действителен”. Неважно, кто и когда спросил.
• Mock — кассир, который записывает, кто и когда спрашивал. Потом вы проверяете журнал.

Fake (Фейк)

Что это

Fake — это упрощённая, но рабочая реализация зависимости. Например, вместо реальной базы данных — in-memory коллекция.

Когда использовать

Пример

Вместо PostgreSQL → in-memory словарь (HashMap).

"Сохранить пользователя" → положить в map
"Найти пользователя по ID" → достать из map

Что даёт: Тест быстрый, не требует реальной БД, но проверяет логику сохранения и чтения.

Spy (Шпион)

Что это

Spy — это обёртка вокруг реального объекта. Он записывает вызовы, но делегирует их реальной реализации.

Когда использовать

Инструменты для Mocking и Stubbing

WireMock (для тестирования API)

WireMock — это инструмент для создания заглушек HTTP API.

Когда использовать реальные зависимости

Что аналитик должен знать

Какие вопросы задать команде

Риски избыточного мокинга

Риски недостаточного мокинга

Пример из реального проекта

Ситуация

API интернет-магазина при создании заказа:

1. Проверяет остатки в БД
2. Вызывает платёжный шлюз
3. Отправляет событие в Kafka
4. Отправляет email через SMTP

Стратегия тестирования

Что проверяют моки на модульном уровне

• Платёжный шлюз: проверить, что вызван с правильной суммой
• Kafka: проверить, что отправлено событие order.created
• SMTP: проверить, что email отправлен на правильный адрес

Распространённые ошибки

Ошибка 1: Мок слишком умный

Мок проверяет не только факт вызова, но и внутреннюю реализацию.

Пример: Мок проверяет, что метод вызван три раза, а важно только то, что вызван хотя бы раз.

Решение: Проверять поведение, а не реализацию.

Ошибка 2: Мок возвращает только успех

Нет тестов на ошибки внешних зависимостей.

Решение: Добавить тесты: “платёжный шлюз вернул ошибку → API вернул 502”.

Ошибка 3: Заглушка не соответствует реальности

Заглушка возвращает {"status": "ok"}, а реальный API — {"success": true}.

Решение: Периодически запускать интеграционные тесты с реальными API.

Ошибка 4: Избыточное мокинге

Заглушены даже простые зависимости, которые можно использовать реальные.

Решение: Для быстрых и стабильных зависимостей (время, случайность) использовать реальные.

Ошибка 5: Нет тестов на отсутствие вызова

Проверяем, что при ошибке валидации не вызывается платёжный шлюз.

Решение: Добавить мок с проверкой, что метод НЕ был вызван.

Резюме

1. Mocking и Stubbing — техники создания дублёров для зависимостей. Позволяют тестировать компонент в изоляции.

2. Stub (заглушка) — возвращает предопределённые ответы. Не проверяет вызовы. Используется, когда важен только результат.

3. Mock (двойник) — запоминает вызовы и проверяет их. Используется, когда важно, как и с какими параметрами вызвали зависимость.

4. Fake (фейк) — упрощённая рабочая реализация. Например, in-memory база данных.

5. WireMock — инструмент для заглушек HTTP API (для интеграционных тестов).

6. Когда заглушать: внешние API, медленные/дорогие/нестабильные зависимости.

7. Когда использовать реальные: БД в интеграционных тестах, простые зависимости.