zer*_*dot 10 testing api integration-testing unit-testing
我们需要使用外部合作伙伴的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应该如何工作的文档/规范.
| 归档时间： |
|
| 查看次数： |
3414 次 |
| 最近记录： |