什么时候应该使用jest快照测试而不是单元测试中的常规断言?

时间:2018-02-05 02:09:48

标签: javascript reactjs unit-testing jestjs enzyme

这个问题只是单元测试。

最近我一直在阅读很多关于快照的内容,我真的很困惑我应该在什么时候使用快照测试而不仅仅是显式断言。我用反应&开玩笑用于单元测试的酶

据我了解,使用快照测试绝对有意义: 检查组件是否以预期的道具呈现我们预期的方式。这样我们就不必为每个道具或每个被渲染的组件等都有一个断言

问题: 1)但是当谈到模糊或点击等用户交互时,可能会出现很多情况。在这种情况下,对每个测试用例进行快照是否有意义?假设我有10个不同的情况,我想测试onBlur。那么有10个不同的快照是否有意义?我知道我们可以使用序列化器过滤掉我们想要在快照上看到的内容,但不仅仅是常规的数据驱动测试(包含开发人员提供的输入和预期输出),只有一个断言更好吗?

2)当我有一个组件,然后呈现几个子组件和&那些儿童组件渲染他们的孩子等。在这种情况下,我安装&然后拍摄快照。那个快照变得非常巨大,我知道我们可以通过使用序列化器来调整它。但在这种情况下,快照真的很棒吗?

3)一般来说,没有太多的快照是坏事吗?

我还遇到了一些奇特的工具,如jest-charm-react等,可以用来充分利用快照测试。但实际上我如何确定使用快照和最佳测试最好的方案。哪个最好使用常规断言?我阅读了很多文章,但有些人对快照印象非常深刻,但这些例子非常基本。有些人完全反对它。认为普通的断言更好。有人可以分享他们的观点吗?

1 个答案:

答案 0 :(得分:0)

  

为什么要进行快照测试?

没有flakiness:因为测试是在命令行运行器而不是真实的浏览器或真实的手机上运行的,所以测试运行器不必等待构建,生成浏览器,加载页面并驱动UI以使组件进入预期状态,该状态往往是不稳定的,测试结果会变得嘈杂。

快速迭代速度:工程师希望在不到一秒的时间内获得结果,而不是等待几分钟甚至几小时。如果测试不像大多数端到端框架那样快速运行,那么工程师根本不会运行它们,或者一开始就不打算写它们。

调试:很容易进入JS中的集成测试代码,而不是尝试重新创建屏幕截图测试场景并调试视觉差异中发生的事情。

这是从here

获得的