Могу ли я использовать Pact Broker для функциональных тестов?

Question

У меня есть служба, которая получает запрос, генерирует электронное письмо, сохраняет его в очередь сообщений (для отправки другим микросервисом) и возвращает httpStatus.Ok. Я хочу проверить, что для разных запросов будет создано соответствующее электронное письмо.

Согласно Контрактным и функциональным тестам мои тесты являются функциональными, а не контрактными. (Если моя служба будет возвращать содержимое электронной почты в качестве ответа api, использование Pact для тестирования контрактов, безусловно, будет уместным).

У меня есть идея использовать инфраструктуру Pact для таких функциональных тестов, в частности
1.Сохранить запрос и ожидаемое сгенерированное электронное письмо в Pact Broker
2. В тестах проверки провайдера отправить запрос и подтвердить сгенерированное электронное письмо с ожидаемым адресом электронной почты.

Есть ли смысл использовать Pact в таких функциональных тестах?
Кто-нибудь знает примеры подобного использования?
Есть ли альтернативные технологии (желательно в.Net Core) для аналогичного тестирования?

Я также рассматриваю https://github.com/approvals/ApprovalTests.Net, но инфраструктура Pact меня больше привлекает.

Связанное примечание: Pact обычно работает с HTTP-запросами / ответами, но Pact V3 (еще не реализованный PackNet) представляет сообщения для служб, которые обмениваются данными через потоки событий и очереди сообщений. Пример, описывающий тесты контрактов пакта сообщений: https://dius.com.au/2017/09/22/contract-testing-serverless-and-asynchronous-applications/ ссылается Pact для MessageQueue: Образец теста провайдера в случае MessageQueues

Answer 1

У меня есть служба, которая получает запрос, генерирует электронное письмо, сохраняет его в очередь сообщений (для отправки другим микросервисом) и возвращает httpStatus.Ok.

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

Что вы не хотите делать с Pact, так это запускать проверочные тесты, а затем проверять, действительно ли электронное письмо было отправлено, было записано в очередь, и что нижестоящий микросервис может его обработать - это выходит за рамки "контрактный тест".

В стороне: что вы определенно можете сделать, так это создать отдельный тест контракта между этим компонентом, который публикует в очереди, и нижележащим компонентом, который получает от него (см. Эту ветку WIP для библиотеки.NET: https://github.com/pact-foundation/pact-net/pull/175)

Я хочу проверить, что для разных запросов будет создано соответствующее электронное письмо.

Если для этих "разных тестов" ответы API имеют предсказуемую форму - тогда да, вы определенно можете сделать это с помощью Pact.

Таким образом, переформулировка вышеизложенного на "У меня есть служба, которая получает запрос, возвращает httpStatus.Ok и отправленное тело электронной почты" является приемлемой ИМО для тестирования контрактов.

Затем вы можете расширить это с помощью различных сценариев:

1. Когда пользователь был успешно создан...
2. Когда пользователь уже существует...
3. и т.п.

Надеюсь, это поможет!

PS Возможно, стоит зайти на https://slack.pact.io/ и поболтать с сообществом дальше.