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

2018-07-03 13:23:15

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

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

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

测试这种情况的最佳实践是什么？

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

整合外部API沙箱并运行每个集成测试。优点：接近真实的API交互。缺点：测试只能在开放的互联网连接下运行，并需要更多时间。

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

其他最佳实践？

谢谢！

相关：如何编写与外部API交互的集成测试？然而，答案是“你没有，你必须真正相信实际的API实际工作。” 在我们看来是不够的。

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

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

我相信当我们与外部API接口时，我们需要做2级验证：

API验证：验证API是否按照其规范和/或我们的理解工作

应用程序功能验证：验证我们的业务逻辑是否符合通过API验证的API的预期

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

Mock API允许我们将应用程序功能的任何运行时错误/异常隔离开来，因此我们不会责怪任何外部方面的问题

对真实API和模拟API执行相同的API验证，以确保真实API以我们期望的方式工作，以及模拟应该正确地模拟真实API

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

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

链接地址: http://www.djcxy.com/p/93493.html