Команда хочет проверять интеграцию с нестабильным внешним сервисом, не делая результат CI зависимым от его доступности. Какой механизм автоматизации применить?
Примените контрактное тестирование: потребитель и поставщик проверяют соблюдение заранее согласованного контракта взаимодействия, а CI запускает эти проверки без обязательного обращения к реальному внешнему сервису. Это снижает зависимость от доступности окружения, но не заменяет небольшое число сквозных проверок реальной интеграции.
В распределённых системах команды часто выпускают сервисы независимо друг от друга. Интеграционные тесты через реальные сервисы дают высокую уверенность, но становятся медленными, дорогими в сопровождении и чувствительными к сетевым сбоям, данным и порядку развертывания.
Контрактное тестирование решает исходную проблему согласования интерфейсов: оно проверяет не всю реализацию поставщика, а конкретные ожидания потребителя — структуру запроса, обязательные поля ответа, типы данных, статусы и важные правила взаимодействия.
Если тест всегда вызывает внешний сервис, падение может означать несовместимость API, недоступность сервиса, ошибку сети, исчерпание тестовых данных или временный сбой самого окружения. Такой тест плохо указывает причину и может блокировать поставку изменений, не связанных с дефектом.
Если полностью заменить внешний сервис заглушкой, тест может стать стабильным, но перестанет подтверждать, что заглушка соответствует реальному API. Главный риск — ложная уверенность: потребитель успешно тестируется против неверно смоделированного поведения.
Потребитель описывает минимальный набор взаимодействий, который ему необходим. Контракт фиксирует, например, метод и маршрут, параметры запроса, обязательные поля ответа, допустимые типы, статус и существенные значения.
На стороне потребителя тест проверяет, что приложение формирует запрос и обрабатывает согласованный ответ. На стороне поставщика отдельная проверка воспроизводит эти ожидания против его реальной реализации. Поэтому изменение поставщика, нарушающее контракт, обнаруживается до совместного сквозного запуска.
Для обмена контрактами используют специализированные инструменты, например Pact, либо формат и процесс, основанные на OpenAPI. Конкретный инструмент вторичен: важны версионирование контракта, запуск проверок в CI и правило, запрещающее публикацию несовместимой версии.
Подход имеет ограничения. Он проверяет только зафиксированные сценарии и не доказывает корректность бизнес-логики, производительность, безопасность или поведение всей цепочки. Контракт должен описывать потребительские ожидания, а не каждую внутреннюю деталь ответа, иначе поставщик будет связан лишними ограничениями.
Практичная стратегия — сочетать контрактные проверки с небольшим набором интеграционных или сквозных тестов против реального сервиса. Контрактные тесты дают быстрый сигнал о совместимости, а реальные проверки подтверждают, что инфраструктура, маршрутизация, аутентификация и фактическая конфигурация работают вместе.
Сервис оформления заказа обращается к сервису расчёта доставки. В CI совместный тест часто падал из-за недоступности тестового сервиса, хотя изменения относились только к обработке ответа.
Рассматривались три варианта. Повторять тест при сбое было быстро внедрить, но это маскировало реальные дефекты и не устраняло зависимость от окружения. Полностью заменить сервис ручной заглушкой повышало стабильность, но не гарантировало соответствие заглушки реальному API. Оставить только сквозной тест давало высокую реалистичность, но сохраняло медленный и неустойчивый контур.
Выбрали контрактное тестирование: потребитель зафиксировал необходимые поля запроса и ответа, а поставщик стал проверять этот контракт в собственном CI. Один сквозной тест оставили для проверки реальной маршрутизации и авторизации. В результате несовместимые изменения стали обнаруживаться на этапе проверки контракта, а доступность внешнего окружения перестала быть условием каждого запуска тестов потребителя.
Основу контракта обычно формирует потребитель, потому что именно он знает, какие свойства взаимодействия действительно использует. Поставщик затем подтверждает выполнение этих ожиданий. Такой подход предотвращает включение в контракт неиспользуемых деталей и уменьшает связанность сервисов.
Нет. Успешный контракт доказывает совместимость только проверенных взаимодействий и условий. Он не проверяет неописанные сценарии, задержки, нагрузку, доступность зависимостей, корректность бизнес-операций и особенности production-конфигурации, поэтому нужен дополнительный риск-ориентированный набор интеграционных проверок.
Проверка может перестать защищать от несовместимости, если старый контракт сразу удалить. Безопаснее поддерживать совместимость переходного периода: сначала добавить новую возможность, убедиться, что потребители её используют, и только затем удалять старый вариант. В CI также нужны проверки совместимости с опубликованными версиями контрактов, а не только с текущей веткой.