javascript - 什么时候应该使用 Jest 快照测试与单元测试中的常规断言？

Question

这个问题只是关于单元测试。

最近我阅读了很多关于快照的文章，我真的很困惑到底什么时候应该使用快照测试还是只使用显式断言。我使用 react & jest & enzyme 进行单元测试

据我所知，使用快照测试绝对有意义:检查组件是否按照我们预期的方式使用预期的 Prop 呈现。这样我们就不必为每个 Prop 或渲染的每个组件等都有断言

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

2) 当我有一个组件依次呈现几个子组件并且这些子组件呈现它们的子组件时怎么样？在那种情况下我挂载然后拍摄快照。这个 snap 变得非常大，我再次知道我们可以通过使用序列化器来调整它。但在这种情况下，快照真的有什么好处呢？

3) 一般来说，快照太多不是一件坏事吗？

我还遇到了一些奇特的工具，例如 jest-glamor-react 等，它们可用于充分利用快照测试。但实际上我如何确定哪种场景最适合使用快照测试以及哪种场景最适合使用常规断言？我读了很多文章，但有些人对快照印象深刻，但示例非常基础。有些人完全反对它并认为简单的旧断言要好得多。有人可以分享他们的观点吗？

Answer 1

Why snapshot testing?

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

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

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

这是从here得到的

现在回答你的问题:

当我必须跟踪 UI 元素时，我会使用快照测试，确保在没有故意进行更改的情况下没有任何更改。快照可帮助您实现这一目标。