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