在端到端测试中处理第三方API请求

Question

我想用端到端测试来测试我的Rest API.据我了解,集成测试之间的区别在于我们不进行内存系统配置,而是使用真实的测试数据库和网络请求.

但我无法理解如何处理第三方API请求(如GitHub或Bitbucket API).

创建假冒Github帐户是否正常,我的测试会提取假数据？

如何处理访问令牌,并非所有服务都是公开的,甚至公共服务都可能因速率限制而失败.

Answer 1

创建假冒Github帐户是否正常,我的测试会提取假数据？

是.E2E测试(与集成测试相比)的目的是验证整个系统是否适用于所有实际系统组件,包括您控制的组件和您未控制的组件.这可能很难设置并且难以维护; 但许多痛点将暴露您生产服务中的真正潜在问题.您的服务如何响应该不稳定性本身就是一个需要测试的功能:您的系统是否崩溃和刻录,或者它是否正常呈现错误消息并支持良好的重试处理？

这也为你提供了一种模拟无法提供的覆盖范围:如果你使用的第三方API是顽皮的并引入了某种突破性变化,那么你的E2E测试将会捕获它.这是继续运行你的E2E套件的一个不错的理由; 不只是在部署期间.

这种测试的下一个层次是混沌工程,你不仅要测试你的生产系统,还要故意引入错误(是的,投入产品),以确保你的服务真正能够应对压力.

如何处理访问令牌,并非所有服务都是公开的,甚至公共服务都可能因速率限制而失败.

应为您的暂存环境配置外部服务的单独沙箱帐户.我不确定你的意思是"并非所有的服务都是公开的",而只是努力让你的登台环境(或测试用户在prod上)尽可能与真正的prod用户相同.对于不支持多访问令牌的服务,您可以获得创意并尝试在其系统中清楚地描绘您的测试数据.

速率限制可能很烦人,但是如果你越来越接近你的测试会超过限制,那么你应该采取一种策略来解决这个问题(与服务协商,获得多个账户,......).

Answer 2

当服务关闭或网络延迟触发某些测试超时时，针对第三方服务运行测试可能会导致测试缓慢且不稳定。更不用说您还面临着触发 API 速率限制的风险，具体取决于您所使用的第 3 方服务。理想情况下，您的测试应该是确定性的，不会随机失败，并且不需要条件逻辑来处理特定测试用例中的错误。如果您期望需要处理错误，那么应该有一个特定的测试用例来覆盖每个构建中运行的这些错误，而不是等待来自第 3 方的非确定性故障。

人们会提出的一个论点是，如果第 3 方 API 由于某种原因而中断，您的测试应该通知您。但一般来说，大多数主要的第 3 方 API 都非常稳定，不太可能做出重大更改。即使确实发生了，这是一种尴尬且令人困惑的方式来发现 API 是否损坏，而且很可能，您的测试不会是您首先听到它的地方。您的客户和生产错误跟踪器更有可能通知您。如果您想跟踪这些服务何时发生变化或停止运行，那么定期进行某种形式的生产检查来验证它是有意义的。

至于如何围绕这些情况编写测试，那就有点棘手了。有一些工具，例如Ruby 中的VCR，可以很好地消除您的语言的互联网连接，并允许您消除、记录和自定义响应（在其自述文件中，有其他语言的类似实现列表）。但是，当您的浏览器在自动化端到端测试中连接到这些资源时，这不起作用。有一些工具可以代理浏览器的 Web 连接，例如Ruby 中的Puffing Billy，但设置过程非常复杂，包括管理安全证书。当某些东西不能正常工作时，这看起来非常脆弱且难以调试。

编写确定性和可维护的测试的最佳选择可能是在测试模式下伪造服务。Thoughtbot 有一个关于这方面的相当不错的视频，这里有一篇来自 CircleCI 的高级文章。本质上，您在测试模式下交换一个适配器，代表您的第 3 方服务集成。也许您可以在本地计算机上做的是可以通过环境变量选择使用真实服务或适配器，以验证测试对两者运行相同。您还可以设置每日构建来针对实际情况运行，以便验证测试是否仍然正常工作，而不会给更频繁的构建带来很多不稳定的情况。不过，我遇到的一个问题是，即使我在该第三方服务上设置了一个测试帐户，当我为了测试新功能（例如添加新功能）而添加或修改信息时，结果也会随着时间而变化。存储库、修改问题等。将您的测试帐户维护为所有测试的一组固定装置需要额外考虑。

我遇到的另一个可能有用的工具是ngrok-tunnel（又是 Ruby）。这仅在您需要第三方服务联系您的应用程序的情况下才相关，因为他们无法通过网络将请求发送到localhost:3000. 如果您配置了某种网络钩子​​，这样的服务可以使测试变得更加简单。