Тест HTTP-клиента проверяет только путь запроса, а мок отвечает на любой HTTP-метод и тело. Какой дефект такая настройка способна скрыть?
Такая настройка может скрыть ошибку в самом HTTP-запросе: например, клиент отправляет неправильный метод или некорректное тело, но мок всё равно возвращает успешный ответ. Это создаёт ложноположительный тест: тест проходит, хотя реальный сервер отклонит запрос или выполнит другую операцию.
Моки применяют, чтобы изолировать тестируемый компонент от внешней системы, ускорить проверки и сделать их воспроизводимыми. Такой подход особенно полезен, когда настоящий сервис недоступен, дорог в использовании или содержит нестабильные данные.
Однако изоляция уменьшает объём проверяемого взаимодействия. Поэтому моку задают правила сопоставления запроса: чем точнее они описывают ожидаемый вызов, тем меньше вероятность, что тест подтвердит ошибочный запрос.
HTTP-запрос определяется не только URL. На его смысл влияют метод, заголовки, параметры, тело, формат данных и иногда порядок или обязательность отдельных полей.
Если мок сопоставляет только путь, ошибочный запрос может получить успешный ответ. В результате тест проверяет лишь то, что код обратился к нужному адресу, но не проверяет соблюдение HTTP-контракта.
Последствия зависят от ошибки: реальный сервер может вернуть ошибку валидации, выполнить чтение вместо изменения данных, выбрать другую версию представления или отклонить запрос из-за неподходящего типа содержимого.
Мок должен проверять все значимые для контракта признаки запроса: HTTP-метод, путь, обязательные query-параметры, необходимые заголовки и структуру тела. При несовпадении он должен явно сообщать об неожиданном запросе, а не молча возвращать стандартный успешный ответ.
Проверять нужно не каждую случайную деталь. Динамические значения вроде идентификаторов, временных меток или токенов следует сопоставлять по правилам формата либо подставлять контролируемыми значениями. Иначе мок станет слишком хрупким и тесты будут падать из-за нерелевантных изменений.
Полезно разделять два уровня проверок. Юнит-тест с моком подтверждает, что клиент формирует ожидаемый запрос и правильно обрабатывает ответы. Интеграционный тест дополнительно проверяет реальное взаимодействие с сервером: маршрутизацию, сериализацию, авторизацию, сетевые ошибки и фактическое поведение серверной стороны.
Мок не должен по умолчанию отвечать на неизвестные запросы. Строгий режим повышает диагностическую ценность теста, но требует поддерживать тестовые ожидания при легитимных изменениях контракта.
Клиент должен создавать резервирование через запрос с методом изменения ресурса и JSON-телом. В тесте мок сопоставлял только путь и возвращал успешный ответ, поэтому дефект, при котором клиент отправлял запрос методом чтения, остался незамеченным. В настоящей среде сервер не создавал резервирование и возвращал ошибку.
Рассматривались три варианта. Полностью заменить мок реальным сервисом — наиболее реалистично, но медленнее, сложнее в настройке и менее удобно для проверки отдельных сценариев ошибок. Оставить широкий мок — быстро, но он сохраняет ложноположительный тест. Настроить строгий мок и добавить отдельную интеграционную проверку — требует поддержки двух уровней, зато разделяет ответственность и лучше локализует дефекты.
Выбрали последний вариант: юнит-тест проверял метод, путь и существенные поля тела, а интеграционный тест подтверждал фактическое создание резервирования. После этого ошибка формирования метода обнаруживалась на уровне теста клиента, а проблемы реального взаимодействия — в интеграционной проверке.
Ответ: те, которые влияют на смысл операции или являются обязательными по контракту. Обычно это метод, путь, значимые параметры, тип содержимого, обязательные заголовки и ключевые поля тела. Случайные или инфраструктурные значения не следует делать точным условием без необходимости: это повышает хрупкость теста и не усиливает проверку бизнес-контракта.
Ответ: мок проверяет ожидания теста, а не реализацию сервера и сеть. Он не выявит, например, ошибку маршрутизации, несовместимую сериализацию на сервере, неверную настройку авторизации, особенности прокси или расхождение фактической серверной валидации с ожиданиями. Для этого нужны интеграционные проверки, а при независимом развитии компонентов — отдельная проверка контракта.
Ответ: нужно фиксировать только стабильные семантические признаки запроса. Динамические поля проверяют по типу, диапазону или общему формату, а порядок полей JSON не считают значимым, если это не предусмотрено контрактом. Такой баланс сохраняет способность обнаруживать неправильные запросы, но не превращает тест в проверку случайного представления данных.