何时应该使用Jest快照测试而不是普通的单元测试断言？

Question

这个问题只涉及单元测试。

最近我一直在阅读关于快照的文章，我真的很困惑，到底何时应该使用快照测试而不是显式断言。我使用react& jest& enzyme进行单元测试。

据我所知，使用快照测试肯定是有意义的： 检查组件是否按预期的props呈现。这样我们就不需要为每个呈现的prop或每个呈现的组件等设置一个断言了

问题： 1）但是当涉及用户交互（如模糊或单击）时，可能会有许多情况。在这种情况下，是否有意义为每个测试用例创建一个snap？假设我有10个不同的用例要测试onBlur。那么为此创建10个不同的snaps有意义吗？我知道我们可以使用序列化器来过滤我们想要在快照中看到的内容，但仅使用单个断言的常规数据驱动测试（其中包含开发人员提供的输入和预期输出）是否更好？

2）如果我有一个组件，它又呈现了几个子组件，并且这些子组件呈现它们的子代等。在这种情况下，我需要挂载然后拍摄快照。那个snap会变得非常庞大。我知道我们可以通过使用序列化器进行调整，但在这种情况下快照有什么好处呢？

3）一般来说，拥有太多的快照是不好的吗？

我还遇到了一些花哨的工具，如jest-glamor-react等，可用于充分利用快照测试。但实际上，我怎样才能确定哪种情况最适合使用快照，哪种情况最适合使用常规断言？我阅读了很多文章，但有些人对快照非常满意，但例子非常基础。有些人完全反对它，并认为纯粹的断言更好。请问有人可以分享他们的观点吗？

- user2821242

---

一些观点：https://kentcdodds.com/blog/effective-snapshot-testing - ggorlen

Answer 1

为什么要使用快照测试？

1. 无法稳定性问题：因为测试是在命令行运行程序中而不是真实浏览器或手机上运行，测试运行程序不必等待编译、生成浏览器，加载页面并驱动UI使组件进入期望状态，这往往容易发生无法稳定性问题且测试结果变得嘈杂。

2. 快速迭代速度：工程师想在少于一秒钟内获得结果，而不是等待数分钟甚至数小时。如果测试不像大多数端到端框架那样快速运行，工程师就不会运行它们，或者根本不会费心编写它们。

3. 调试：与尝试重新创建屏幕截图测试场景并调试视觉差异相比，轻松地进入JS集成测试代码。

此段内容来源于这里 现在回答你的问题：

当我需要跟踪UI元素时，确保没有任何更改而没有有意进行过这些更改时，我将会使用快照测试。快照测试能够帮助你实现这一目标。

- codejockie