【问题标题】:How to write automated tests when using cloud APIs?使用云 API 时如何编写自动化测试?
【发布时间】:2018-04-17 10:01:42
【问题描述】:

我正在添加一个开源项目,在这种情况下使用一些 Azure 云功能,但同样的一般问题适用于任何云 API。我想为我的代码编写测试,但测试结果依赖于我正在使用的云服务中发生的某些事情,为了实现这一点,我需要向云服务提供凭据。在私人项目中,我当然可以将我的云凭证添加到测试环境中,但对于公共/开源项目,我不能这样做。我可以很容易地在本地进行测试,但是这个项目使用 CI(就像许多 OSS 项目一样),所以这真的做不到。

一种方法似乎是使用mock 或类似的东西,但实际上这似乎并不能测试事情是否按照应有的方式发生,并且让我觉得实现 100% 覆盖率的方法几乎毫无意义。

是否有任何“虚拟测试云”环境可以旋转以创建与相关云服务相同的接口,但仅用于测试?这些如何处理副作用(有问题的代码会创建一个 DNS 条目,理想情况下会使用系统的解析器而不是另一个云调用来测试 DNS 条目的实际存在)?

人们如何进行这种测试?

【问题讨论】:

    标签: unit-testing testing automated-tests cloud tdd


    【解决方案1】:

    我从spike solution 开始学习如何传递所需的凭据。有了这些知识,我可以 TDD 一个 acceptance test 来调用一个简单的 API 并获得一个“成功”的结果。

    我从我的存储库中排除了凭据。相反,我包含一个带有说明的模板文件。

    从那里,我下拉到 TDD 发送请求和接收响应的单元测试。 我不测试与任何服务的实际通信。 相反:

    • 测试请求的内容。
    • 创建响应并测试它们的处理方式。这使得测试各种错误条件变得非常容易。

    一旦我完成了 TDD 的凭据、请求和响应,我就会使用我所谓的 spike test 来确认一切实际上都在工作。基本上,这在我可以快速破解的任何事情中使用非自动确认。

    【讨论】:

    • 虽然这看起来很合理,但在开源项目的世界中,自动化测试是主要的测试方式,我不太明白这将如何可靠地工作。我预见到的一个主要问题是,如果 API 发生变化,事情就会中断,但自动化测试将继续通过。
    • 这就是你还需要一些验收测试的地方,它本质上是为了测试合同没有改变。在测试金字塔中的一个级别,它们应该是最小的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-09-21
    • 2019-03-19
    • 1970-01-01
    • 2019-04-12
    • 2010-09-28
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多