Конечно.
Итак, какие могут быть проблемы при использовании моков?
Моки дают ложное чувство безопасности
- Мок возвращает именно тот ответ, который вы запрограммировали, - тест «зелёный», но в реальном сервисе ответ может отличаться.
- Из-за этого баги в интеграции или обновлении внешнего API останутся незамеченными.
Моки влияют на чрезмерную связанность тестов и реализации
- Тесты проверяют, что именно вы вызвали конкретный метод или передали определённый параметр - меняете внутреннюю логику — падают сотни тестов.
- В результате рефакторинг превращается в пытку по правке моков.
Это дорого поддерживать
- Любое изменение контракта (сигнатуры метода, формата данных) требует правок и в самих тестах, и в мок-заглушках.
- В крупных кодовых базах список «куда добавить новый мок-ответ» растёт очень быстро.
Скрытые интеграционные проблемы
- Моки не проверяют сетевые настройки, время ответа, сериализацию/десериализацию, реальные ошибки аутентификации.
- После релиза неожиданно возникают time-out’ы, ошибки 401/403 или «сломанные» JSON-ответы.
Потеря покрытия «тёмных углов»
- Если вы замокали весь стек зависимостей, не прогоняете сценарии end-to-end, не увидите проблем с конфигурацией, маршрутизацией, сертификатами и т. п.
Неправильное моделирование ошибок
- Мок может симулировать только заранее предустановленные ошибки (500, таймаут), но редко - непредвиденные ситуации: обрывы соединения, нестабильные данные, череду событий.
- Ваш код может неправильно обрабатывать реальные случаи «плавающих» ошибок.
Сложности при тестировании асинхронности
- Моки зачастую возвращают ответы мгновенно, а реальные сервисы - с задержкой, в другом потоке, иногда в виде веб-хуков.
- Асинхронные баги (гонки состояний, дедлоки) остаются скрытыми.
Размывание ответственности
- Разработчики начинают писать логику под «удобство» моков: например, неявные зависимости, чрезмерное хакирование точек подключения, упрощённое управление временем.
- В продакшене такой код ведёт себя иначе, и отладка «наживых» багов превращается в кошмар.
Как смягчить эти проблемы?
- Комбинируйте мок-тесты с интеграционными и e2e-тестами.
- Мокируйте только внешние зависимости, а внутренние - по возможности оставляйте реальными.
- Используйте контракт-тестирование (consumer-driven contracts) для проверки соответствия API.
- Автоматизируйте обновление мок-ответов на основе спецификаций (OpenAPI, gRPC).
- Регулярно прогоняйте тесты в staging-среде с реальными сервисами.