Контракты PACT на конечную точку - PullRequest
Новая
       11

Контракты PACT на конечную точку

0 голосов
/ 22 марта 2019

Привет, я провожу предварительные исследования по контрактному тестированию с использованием PACT. В парадигме, в которой я использую пакт-брокер для размещения пактов, я с высокого уровня понимаю, что на стороне потребителя должен быть контрактный тест, который запускает набор тестов для сервера пакт-макета ... который затем будут опубликованы в брокере пакта. Провайдеру также потребуется контракт, в котором он использует пакт, созданный потребителем в брокере пактов, для запуска своего теста.

У меня такой вопрос: на стороне потребителя, нужно ли писать несколько разных тестов для каждой конечной точки?

Ответы [ 2 ]

1 голос
/ 23 марта 2019

Короткий ответ - да.

Это зависит от того, что делает каждая из конечных точек API.Но обычно каждая конечная точка может обрабатывать разные операции, и в зависимости от запроса вы захотите убедиться, что ваш код может обработать его (если он использует все эти операции - что важно).

, например, следующеедовольно типично для CRUD-подобной службы:

  1. GET /<resource> с действительным запросом, return 200 и телом ресурса
  2. GET /<resource> с неверным запросомвернуть 400 и тело ошибки
  3. GET /<resource> без токена аутентификации, вернуть 401
  4. POST /<resource> с действительным запросом, вернуть 201 иидентификатор ресурса / тело
  5. DELETE /<resource> ... и т. д.

Внутри каждой операции и ресурса могут быть полиморфные полезные нагрузки (запросы или ответы).Если ваш потребительский код должен иметь дело с этим, он также должен иметь тесты для них.

Вы можете найти эту страницу в наших документах, полезных по этой теме.

1 голос
/ 22 марта 2019

Если под конечной точкой вы подразумеваете разные API на разных доменах, тогда да.

Концепция пакта заключается в том, чтобы взаимодействовать между любой парой потребитель / поставщик. Например, если у вас есть внешний интерфейс SPA (потребитель), который использует 2 разных API (провайдера), например API аутентификации (т.е. auth.yourdomain.com) и API данных (например, data.yourdomain.com), вы захочет записать взаимодействия между вашим веб-интерфейсом и API аутентификации в виде одного контракта и другого контракта между веб-интерфейсом и вашим API данных.

Каждый из этих контрактов будет иметь по крайней мере одно взаимодействие, но может иметь много, например, когда вы делаете запрос GET в корневом каталоге API аутентификации, он возвращает X, если вы выполняете POST при / auth с имя пользователя / пароль в теле, возвращает Y и т. д.

Имеет ли это смысл?

...