Какой дефект не обнаружит тест API, если внешняя система полностью заменена моком?
Такой тест не обнаружит дефект реального взаимодействия с внешней системой: например, несовместимый формат запроса, ошибку сериализации, неверную аутентификацию или отличие фактического HTTP-поведения от настроек мока. Он проверяет логику тестируемого сервиса в заранее заданных условиях, но не подтверждает совместимость с настоящим поставщиком.
Моки появились как средство изоляции тестируемого компонента от медленных, нестабильных или недоступных зависимостей. Они позволяют воспроизводимо проверять ветвления, обработку ошибок и повторные попытки без запуска всей интеграционной среды.
Однако изоляция решает одну проблему ценой другой: тест перестаёт наблюдать реальный протокол взаимодействия. Поэтому моки дополняют интеграционные проверки, а не заменяют их.
Предположим, сервис отправляет заказ во внешний сервис доставки. Мок принимает ожидаемую структуру запроса и возвращает успешный ответ, но реальный сервис требует другое имя поля, иной формат даты или дополнительный заголовок.
Тест с моком останется зелёным, потому что его поведение определяется настройками мока. После выката возникнет ошибка интеграции, хотя бизнес-логика и весь набор изолированных тестов могут быть корректными.
Мок проверяет только взаимодействие с моделью зависимости: был ли вызван нужный метод, с какими параметрами и какой ответ нужно вернуть. Если модель настроена неверно или слишком упрощённо, тест закрепляет ошибочное предположение о внешней системе.
Для проверки совместимости нужен хотя бы один канал, где участвует реальная реализация зависимости или её управляемый тестовый стенд. Такой тест должен проверять не только успешный сценарий, но и фактические правила протокола: HTTP-метод, путь, заголовки, сериализацию, коды ответа, формат ошибок, тайм-ауты и особенности повторных запросов.
Практичный компромисс — оставить моки для быстрых проверок логики, а интеграционные проверки запускать отдельно и реже. Если полноценная внешняя система недоступна, применяют её официальную песочницу, контейнеризированный аналог или контрактную проверку; при этом последний вариант подтверждает согласованные ожидания, но не гарантирует отсутствие всех дефектов реальной инфраструктуры.
Важно не превращать мок в копию всей внешней системы. Чем сложнее его внутренняя логика, тем выше стоимость поддержки и риск тестировать сам мок вместо приложения.
Команда проверяла сервис возвратов. В моках платёжного провайдера успешный ответ содержал идентификатор операции как строку, а в рабочем API провайдера после обновления он стал возвращаться числом. Локальные тесты не выявили проблему, поскольку преобразование ответа проверялось относительно мока.
Рассматривались варианты:
Выбрали третий вариант, сохранив моки для быстрых сценариев и добавив отдельный интеграционный набор в конвейер перед релизом. В результате локальные тесты продолжили быстро проверять логику, а несовместимое изменение формата стало обнаруживаться до выката.
Нет. Она подтверждает, что код сформировал вызов согласно заданному ожиданию. Но само ожидание может расходиться с документацией или фактическим поведением поставщика, а проверка не показывает, как реальный сервер обработает запрос.
Ошибки сериализации и десериализации, неверные заголовки, различия в кодах и форматах ошибок, проблемы TLS и аутентификации, тайм-ауты, ограничения размера запроса, особенности пагинации и повторной доставки событий. Мок обнаружит их только при явном моделировании, а часть инфраструктурных проблем вообще невозможно достоверно воспроизвести без реального окружения.
Нет. Реальный тест обычно ценнее для проверки совместимости, но он может быть медленным, нестабильным, дорогим или зависеть от данных и квот внешней системы. Поэтому используют слои проверок: моки для изолированной логики, интеграционные тесты для протокола и среды, а ограниченный набор проверок с реальным поставщиком — для критичных путей и обнаружения расхождений.