Сервис заказов и клиентское приложение выпускаются независимо. Фрагмент показывает, что клиент ожидает обязательное поле, которого нет в текущем ответе сервиса:
{
"запрос": {"метод": "GET", "путь": "/orders/42"},
"ожидаемый_ответ": {"статус": 200, "тело": {"id": 42, "итого": 1500, "валюта": "RUB"}},
"фактический_ответ": {"статус": 200, "тело": {"id": 42, "итого": 1500}}
}
Какой механизм процесса качества должен обнаруживать такое нарушение до совместного выпуска сервисов?
Нужны контрактные тесты, в частности потребительские контракты, которые проверяют соглашение между клиентом и сервисом. Клиент фиксирует обязательные свойства запроса и ответа, а сервис автоматически подтверждает соответствие этому контракту в CI до публикации новой версии.
В примере проверка обнаружит отсутствие поля валюта ещё до интеграционного сбоя. Это не просто проверка доступности сервиса: контролируется совместимость его внешнего поведения с ожиданиями потребителя.
При независимом выпуске сервисов полные сквозные проверки становятся дорогими, медленными и хрупкими. Команды стремились получать более раннюю обратную связь о несовместимых изменениях, не поднимая всю распределённую систему для каждой проверки.
Контрактное тестирование решает более узкую задачу: проверяет договорённость между взаимодействующими компонентами. Оно дополняет модульные, интеграционные и сквозные тесты, а не заменяет их.
Клиент может корректно работать с тестовой версией сервиса, но сломаться после изменения формата ответа в production. Наличие HTTP-статуса 200 не доказывает совместимость: поле может исчезнуть, изменить тип, стать необязательным или получить другое значение.
Если проверять это только сквозным сценарием, ошибка обнаружится поздно, а причина будет скрыта среди проблем окружения, данных и маршрутизации. Если вообще не проверять контракт, независимость релизов превращается в неявную зависимость от ручной координации команд.
Потребитель описывает значимые для него взаимодействия: метод, путь, параметры, структуру ответа и правила сопоставления значений. Провайдер запускает проверку этого описания против своей реализации. В CI сборка провайдера не должна считаться совместимой, если обязательное ожидание потребителя нарушено.
Минимальная модель контракта может выглядеть так:
Важно различать обязательное и необязательное поведение. Контракт не должен фиксировать каждую случайную деталь ответа: лишние поля часто безопасны, а жёсткая проверка порядка полей, внутренних идентификаторов или нестабильных значений создаёт ложные падения.
При изменении провайдера полезно поддерживать обратную совместимость: сначала добавить новое поле, затем перевести потребителей, и только после этого удалять старое. Если изменение несовместимо, нужен явно согласованный новый контракт или версия интерфейса.
Контрактные тесты не доказывают бизнес-корректность сервиса, надёжность базы данных, производительность или корректность всего пользовательского сценария. Поэтому сохраняются модульные проверки провайдера и потребителя, а для критичных путей — ограниченный набор сквозных тестов.
Основной компромисс — баланс между ранней обратной связью и стоимостью сопровождения контрактов. Чем больше несущественных деталей в контракте, тем выше шум и тем меньше доверие команды к результату.
Команда мобильного приложения и команда API выпускали версии независимо. После изменения ответа API приложение получило статус 200, но перестало отображать сумму заказа: поле было переименовано без предупреждения.
Рассматривались три варианта. Полный набор сквозных тестов лучше имитировал реальный путь пользователя, но требовал стабильного окружения и давал позднюю обратную связь. Ручная сверка изменений была дешёвой на старте, однако зависела от дисциплины и плохо масштабировалась. Проверка общей схемы API выявляла структурные расхождения, но не показывала, какие поля действительно критичны конкретному потребителю.
Выбрали потребительские контракты для мобильного клиента и нескольких ключевых интеграций. В контракт включили только используемые поля и критичные правила, а проверку провайдера добавили в CI. В результате несовместимое переименование стало обнаруживаться при изменении API, при этом команды сохранили независимый выпуск совместимых изменений.
1. Достаточно ли проверить контракт только на стороне потребителя?
Нет. Потребительская проверка показывает, что тестовый двойник или доступная версия провайдера отвечает ожидаемым образом, но не гарантирует, что новая версия реального провайдера сохранит это поведение. Нужна верификация контракта провайдером либо другой надёжный процесс подтверждения совместимости.
2. Следует ли добавлять в контракт весь JSON-ответ?
Обычно нет. В контракт включают только наблюдаемое и значимое для потребителя поведение: необходимые поля, типы, ограничения и важные варианты ответа. Полная фиксация нестабильных деталей увеличивает связанность команд и превращает безопасные изменения в формальные нарушения.
3. Заменяют ли контрактные тесты сквозные тесты?
Нет. Контракт проверяет совместимость границы между компонентами, но не подтверждает, что несколько сервисов вместе правильно выполняют бизнес-процесс. Сквозные тесты остаются нужными для небольшого числа критичных пользовательских путей, тогда как контракты дают более быстрый и локальный сигнал о нарушении интерфейса.