Георгий попал в команду, где каждый unit-тест использовал моки для всех внешних зависимостей.
База данных — мок. HTTP-запросы — мок. Файловая система — мок. Георгий не понимал, зачем такая изоляция, если можно тестировать с реальными компонентами.
Первый конфликт: модуль платежей
Георгию поручили интеграцию с API платежной системы.
Он написал тесты, которые делали реальные запросы к тестовому серверу платежного провайдера. Код-ревью отклонили — требовали замокировать HTTP-клиент.
| Аспект | Подход Георгия (реальные запросы) | Требование команды (моки) |
| Скорость тестов | 45 секунд на 12 тестов | 0.8 секунды |
| Стабильность | Падали при проблемах с сетью | Всегда стабильны |
| Реалистичность | Проверяли реальное API | Проверяли предположения о API |
| Найденные баги | 2 (изменился формат ответа) | 0 |
Георгий согласился на моки, но настоял на дополнительных интеграционных тестах раз в день.
Инцидент через месяц
Платежный провайдер обновил API без предупреждения.
Все замокированные unit-тесты проходили успешно. Код уехал в продакшн. Реальные платежи начали падать с ошибкой валидации.
Интеграционные тесты Георгия, которые запускались по расписанию, поймали проблему на следующий день. Но ущерб уже был — 6 часов недоступности платежей.
Компромиссное решение: пирамида тестов
Команда села за круглый стол и выработала стратегию.
Георгий предложил разделить тесты по уровням и использовать оба подхода:
| Уровень | Тип зависимостей | Частота запуска | Количество |
| Unit с моками | Все замоканы | При каждом сохранении | 150 |
| Интеграционные | Реальная БД, моки внешних API | Перед коммитом | 35 |
| E2E с реальными API | Все реальное | Раз в час в CI | 8 |
| Contract тесты | Проверка контрактов с внешними API | Два раза в день | 12 |
Три месяца спустя: практические выводы
Георгий вел статистику по своему модулю.
Unit-тесты с моками отлично проверяли внутреннюю логику: расчет комиссий, валидацию данных, форматирование запросов. Они работали мгновенно и позволяли быстро итерироваться.
Но моки не ловили проблемы несоответствия с реальными системами. Три раза за квартал внешние API меняли формат ответов — тесты с моками не замечали.
Когда Георгий использует моки сейчас
Он выработал собственную систему принятия решений:
- Тестирование чистой бизнес-логики — всегда моки
- Проверка обработки ошибок внешних систем — моки удобнее
- Тестирование форматирования данных для API — реальные запросы к sandbox
- Проверка производительности — моки искажают картину
Георгий понял главное: моки отлично изолируют код для тестирования логики, но создают ложное чувство безопасности насчет интеграций
Сейчас в его модуле 90% unit-тестов используют моки для скорости разработки. Но 10% интеграционных тестов с реальными зависимостями ловят критические проблемы, которые моки просто не видят.
Команда приняла этот подход. За последние три месяца — ни одного инцидента с платежами в продакшене.