>我们需要使用外部合作伙伴的API。API 处于良好状态，我们可以访问可用于自动测试的沙盒环境。
我们已经使用单元测试测试了外部 API 的每一次调用，但在涉及外部合作伙伴的复杂操作时，不确定集成测试的最佳实践。
示例：我们服务的每个用户也从我们的外部合作伙伴处获得了一个用户对象。在此用户对象上执行外部 API 调用 X 时，我们希望对象 Y 出现在该用户的集合 Z 中（我们必须使用不同的调用进行查询）。
测试此类用例的最佳实践是什么？
-
尽可能多地模拟外部 API 并依靠单元测试来完成它们的工作？优点：测试运行速度快，独立于互联网连接。缺点：我们的模拟中的错误可能会导致误报。
-
集成外部 API 沙箱并针对它运行每个集成测试。优点：接近现实生活中的 API 交互。缺点：测试只能在开放的互联网连接下运行，需要更多时间。
使用模拟数据和沙盒 数据的混合，设置布尔值以在需要时在内部（=模拟）和外部（=沙盒）环境之间切换。优点：可靠的测试。缺点：设置起来可能很痛苦。
其他最佳实践？
谢谢！
相关：如何编写集成测试以与外部 API 交互？然而，答案是"你没有。你必须真正相信实际的API确实有效"，在我们看来是不够的。
[编辑] 我们担心仅针对我们的外部 API 应该如何工作的假设（即使它们基于单元测试）而不是针对实际 API 的集成测试会给我们留下误报。我们需要的是一个测试，验证我们的假设（模拟）实际上是正确的 - 不仅在单元测试的上下文中，而且在具有多个步骤的复杂操作的上下文中。
验证可能是一个很好的例子：如果我们弄乱了集成代码并发送了格式不正确的数据，或者在我们发送它的上下文中没有任何意义的数据，因为我们错过了一个步骤，该怎么办？我们的模拟 API 不验证（或仅在非常有限的范围内）仍将返回有效数据，而不是传递我们从真实 API 收到的错误。
我相信当我们与外部 API 接口时，我们应该进行 2 个级别的验证：
- API 验证
- ：验证 API 是否根据其规范和/或我们的理解工作
- 应用功能验证：验证我们的业务逻辑是否按照对通过 API 验证的 API 的期望工作
在我们的例子中，我们使用模拟 API 以及真实和模拟 API 验证。
- 模拟 API 允许我们仅隔离应用程序功能的任何运行时错误/异常，因此我们不会将问题归咎于任何外部方
- 对真实和模拟 API 执行相同的 API 验证，以确保真实的 API 按照我们预期的方式工作，并且模拟的 API 应该正确模拟真实的 API
如果在此过程中，外部 API 发生更改，API 验证可能会变为红色，从而触发模拟 API 中的更改。模拟 API 中的更改可能会使应用验证变为红色，从而触发应用实现中的更改。这样，您就不会错过外部 API 和应用程序实现之间的任何差距（理想情况下）。
拥有模拟 API + API 验证的另一个额外好处是，您的开发人员可以将其用作 API 应该如何工作的文档/规范。