我可以使用Pact broker进行功能测试吗？

Question

我有一个服务，它接收请求，生成电子邮件，将电子邮件保存到消息队列(由其他微服务发送)，并返回httpStatus.Ok。我想测试一下，对于不同的请求，将生成相关的电子邮件。

根据Contract Tests vs Functional Tests的说法，我的测试是功能测试，而不是合同测试。(如果我的服务将返回电子邮件内容作为api响应，那么使用Pact进行合同测试肯定是合适的)。

我有一个想法是使用Pact基础设施进行这样的功能测试，特别是

 1.Save request and expected generated email into Pact Broker

 2. In provider Verify tests submit the request and verify generated email with expected email.  

在这样的功能测试中使用Pact有意义吗？

有谁知道类似用法的例子吗？

有没有替代技术(最好是在.Net核心中)进行类似的测试？

我也在考虑https://github.com/approvals/ApprovalTests.Net，但Pact基础设施更吸引我。

相关注释: Pact通常与http请求/响应一起工作，但Pact V3 (尚未由PackNet实现) Introduces messages for services that communicate via event streams and message queues。下面的示例描述了Pact for MessageQueue's : Sample Provider test in case of MessageQueues引用的https://dius.com.au/2017/09/22/contract-testing-serverless-and-asynchronous-applications/的消息约定约定测试

Answer 1

我有一个服务，它接收请求，生成电子邮件，将电子邮件保存到消息队列(由其他微服务发送)，并返回httpStatus.Ok。

因此，正如您所说，使用Pact，虽然其意图不是传统意义上的功能测试工具，但几乎不可避免地不测试功能。目标实际上是测试系统之间的契约(这创建了一个小的灰色区域，您需要在其中决定什么是最适合您的测试策略)。

对于Pact，您不想做的是运行验证测试，然后检查电子邮件是否已实际发送，是否已写入队列，以及下游微服务是否可以处理它-这将超出“合同测试”的范围。

顺便说一句:您肯定可以做的是，在发布到队列的组件和从队列接收的下游组件之间创建一个单独的协定测试(参见.NET库的WIP分支：https://github.com/pact-foundation/pact-net/pull/175)

我想测试一下，对于不同的请求，将会生成相关的电子邮件。

如果对于那些“不同的测试”，来自API的响应是可预测的-那么是的，你绝对可以用Pact来做这件事。

因此，将上面的语句改写为“我有一个接收请求的服务，返回httpStatus.Ok，并发送电子邮件正文”是一种可接受的合同测试IMO。

然后，您可以通过各种场景对此进行扩展：

已成功创建用户时的exists...

• etc.

• ...用户已执行exists...

• etc.

时的

希望这能有所帮助！

P.S.可能值得跳到https://slack.pact.io，并在那里与社区进行更深入的交谈。