1

我有一个接收请求、生成电子邮件、将电子邮件保存到消息队列（由其他微服务发送）并返回 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 的示例提供程序测试

4

1 回答 1

1

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

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

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

顺便说一句：你绝对可以做的是在发布到队列的这个组件和从它接收的下游组件之间创建一个单独的合约测试（参见.NET 库的这个 WIP 分支：https ://github.com/契约基金会/契约网/pull/175）

我想测试是否会针对不同的请求生成相关的电子邮件。

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

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

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

  1. 当用户创建成功...
  2. 当用户已经存在...
  3. 等等

希望有帮助！

PS 可能值得进入https://slack.pact.io并在那里与社区进一步聊天。

于 2020-05-25T00:23:30.057 回答