Клиент показывает статус заказа и читает из ответа id и status. Если API переименует поле, клиент может перестать работать. В примере Mentoring.digital контракт Pact фиксирует нужное взаимодействие, а проверка поставщика сравнивает его с фактическим ответом тестового API.
Как записать ожидание на стороне клиента
Для состояния «заказ 42 существует и оплачен» укажите запрос GET /orders/42, ожидаемый код 200 и поля, которые использует экран. Запустите настоящий код клиента против тестового сервера Pact. Тест проверяет, что клиент отправил нужный запрос и смог разобрать ответ.
HTTP 200
Content-Type: application/json
{
"id": 42,
"status": "paid"
}Это пример тела ответа, а не полный файл контракта. Для идентификатора можно проверить конкретное значение, если клиенту важно получить тот же заказ. Для поля, где важен только формат, выберите подходящий matcher. Не включайте в обязательные ожидания поля, которые клиент не использует.
Как поставщик проверяет контракт
После теста клиента Pact сохраняет ожидаемое взаимодействие. При проверке поставщика подготовьте указанное тестовое состояние, затем отправьте запрос в тестовый экземпляр API и сравните ответ с ожиданиями. Если status заменили на state, проверка обязательного поля должна выявить несовместимость. Дополнительное поле, которое клиент игнорирует, обычно допустимо при стандартном сопоставлении ответов Pact.
Что проверять отдельно
Для отсутствующего заказа запишите другое состояние и отдельное взаимодействие с ожидаемым кодом ошибки. Правила смены статуса и работу всей системы проверяйте подходящими функциональными сценариями. Контракт описывает проверенные взаимодействия конкретного потребителя.
Практику с клиентскими ожиданиями можно включить в обучение тестированию API. Выбрать границы контракта для своего сервиса поможет разбор с наставником по QA.
