Контрактный тест проверяет ожидания на границе сервисов и обнаруживает несовместимое изменение раньше, чем команды соберут полную общую среду.
Фиксируйте наблюдаемое
Проверяйте метод, путь, обязательные поля, типы, коды и значимую семантику, не привязываясь к внутренней реализации поставщика. Контракт узкий.
Подключите обе стороны
Потребитель публикует реальные ожидания, а поставщик проверяет их на каждой сборке до выпуска. Неиспользуемые требования удаляйте.
Не заменяйте интеграцию
Контракт не доказывает сетевые настройки, права, таймауты и полный бизнес-путь, поэтому оставьте несколько реальных интеграционных проверок. Баланс нужен.
При каждом версионировании обязательно храните проверяемую связь контрактного теста с конкретным активным потребителем и его владельцем, чтобы устаревшее ожидание не блокировало дальнейшее развитие API после документально завершенной миграции последнего клиента.
Правила изменения описаны в статье про версионирование API. Уровни тестов распределяйте по рискам.
