【问题标题】:Frontend testing - Mocking server response - json generator vs static responses前端测试 - 模拟服务器响应 - json 生成器与静态响应
【发布时间】:2018-08-15 04:29:17
【问题描述】:

我有一个服务器,它对 HTTP 请求执行一些复杂的业务逻辑操作。我想使用该服务器为前端编写单元测试和功能测试。在网上阅读了很多之后,我发现有很多方法可以实现这一点,我认为最适合我们情况的两种方法是:

  1. 保存静态响应 - 对于我要测试的每个场景,记录服务器响应,将响应保存在存储库中的文件中并在测试中使用。
  2. 创建一个 json 响应生成器,我可以轻松地为测试动态创建内容。

我在每个方面看到的优点和缺点: 对于静态文件:

优点:如果设置正确以记录后端响应 - 应该很容易实施新测试。

缺点:如果 API 发生变化,我没有好的方法来映射所有使用该 API 并知道更新测试的文件。这样做的结果是,甚至很难知道支持这种变化所需的变化范围是什么。

对于 JSON 生成器:

优点:很容易更改 API 响应,因为它在一个地方。

缺点:这方面的升级要复杂得多,并且需要一段时间才能轻松快速地添加测试。

当然,每种都有更多的优点和缺点,但在我看来,这些是两者之间最矛盾的。

我的问题是:

  1. 还有更多我们忽略的选项吗? (我不希望单元测试通过网络模拟服务器)
  2. 您推荐这两个中的哪一个,为什么?
  3. 这方面的最佳做法是什么?

谢谢,

【问题讨论】:

    标签: javascript unit-testing mocking frontend


    【解决方案1】:

    我会说这属于集成测试的范畴。您的测试(理想情况下)不应该进行外部网络调用 - 前端或后端 - 所以模拟数据是要走的路。我将分享我对您的两个选项的想法:

    静态响应 - 这是最直接的方法,只要真实服务器响应没有太大差异,就不会出错。将静态响应与“真实”API 同步成为这里的关键因素。这需要您与开发 API 本身的团队密切沟通,或者如您所说,设计一种检测相关更改的方法。

    响应生成器 - 我相信这是更稳健的方法,因为对 API 的任何更改都会反映在生成的响应中。它还涉及测试的集成方面,因为如果响应是由运行 API 的相同代码生成的,则可以确保包含任何新更改。

    我建议通过后端代码生成响应并将集成测试合并到您的构建步骤中。话虽如此,如果您在一个前端团队中使用一个在团队不知情的情况下不断变化的 API,也许您需要研究您的通信方法,以便两个团队可以同步并且可以最大限度地减少意外变化。

    【讨论】:

    • 我们也有集成测试,这已经涵盖了。 API 没有太大变化,当它发生变化时,它会被传达 - 但一旦传达,您希望在前面进行更改,并确信我们涵盖了所有情况。
    猜你喜欢
    • 2017-03-08
    • 2015-10-19
    • 2014-10-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-10-23
    • 2013-07-28
    相关资源
    最近更新 更多