集成测试：模拟外部API与使用外部API沙箱

Question

我们需要使用外部合作伙伴的API。 API处于良好状态，我们可以访问可用于自动测试的沙箱环境。

我们已经使用单元测试测试了外部API的每一次调用，但在涉及外部合作伙伴方面的复杂操作时，不确定集成测试的最佳实践。

示例：我们服务的每个用户也在我们的外部合作伙伴处获得了一个用户对象。在此用户对象上执行外部API调用X时，我们希望对象Y出现在此用户的集合Z中（我们必须使用不同的调用进行查询）。

测试此类案例的最佳做法是什么？

• 尽可能地模拟外部API 并依靠单元测试来完成他们的工作？优点：测试运行速度快，独立于互联网连接。缺点：我们的嘲笑中的错误可能导致误报。

• 集成外部API沙箱并针对它运行每个集成测试。优点：接近现实生活中的API交互。缺点：测试只能通过开放的互联网连接运行，并且需要更多时间。

• 使用模拟和沙箱数据的混合，设置布尔值以在需要时在内部（=模拟）和外部（=沙箱）环境之间切换。优点：可靠的测试。缺点：设置可能会很痛苦。

• 其他最佳做法？

谢谢！

---

相关：How are integration tests written for interacting with external API?然而，答案是＆＃34;你不是。你必须真正相信实际的API实际上是有效的。＆＃34;我们认为还不够。

[编辑]我们担心集成测试只针对我们假设外部API应该如何工作（即使它们基于单元测试） - 而不是针对实际的API - 会给我们带来误报。我们需要的是一个测试，它验证我们的假设（模拟）实际上是正确的 - 不仅在单元测试的上下文中，而且在具有多个步骤的复杂操作的上下文中。

验证可能是一个很好的例子：如果我们搞错了集成代码并发送格式错误的数据或数据，这些数据或数据在我们发送的上下文中没有任何意义，因为我们错过了一个步骤？我们的模拟API不会验证（或仅在非常有限的范围内）仍然会返回有效数据，而不是传递我们从真实API收到的错误。

Answer 1

我认为在与外部API接口时，我们需要进行2级验证：

• API验证：验证API是否符合其规范和/或我们的理解
• 应用功能验证：验证我们的业务逻辑是否符合对API验证的API的期望

在我们的案例中，我们使用模拟API 以及真实和模拟API验证。

• 模拟API允许我们将任何运行时错误/异常仅隔离到应用程序功能，因此我们不会责怪任何外部方面的问题
• 针对真实API和模拟API执行相同的API验证，以确保真实的API以我们期望的方式工作，以及模拟人员应该正确模仿真实的

如果在此过程中，外部API发生变化，API验证可能会变为红色，从而触发模拟API中的更改。模拟API的更改可能会使应用验证变为红色，从而触发应用实施中的更改。这样您就不会错过外部API和应用程序实现之间的任何差距（理想情况下）。

进行模拟API + API验证的另一个好处是，您的开发人员可以将其用作API应该如何工作的文档/规范。