Блог

Главная - Вопросы по программированию - ПАКТНЫЕ контрактные тесты для каждой конечной точки

ПАКТНЫЕ контрактные тесты для каждой конечной точки

#testing #pact

#тестирование #пакт

Вопрос:

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

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

Ответ №1:

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

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

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

  1. ПОЛУЧЕНИЕ /<resource> с действительным запросом, возвратом 200 и телом ресурса
  2. ПОЛУЧАЕМ /<resource> с ошибочным запросом, возвращаем 400 и текст ошибки
  3. ПОЛУЧИТЬ /<resource> без токена аутентификации, вернуть 401
  4. ОПУБЛИКОВАТЬ /<resource> с действительным запросом, возвратом 201 и идентификатором ресурса / телом
  5. УДАЛИТЬ /<resource> … и так далее

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

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

Ответ №2:

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

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

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

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