use*_*242 7 javascript unit-testing reactjs jestjs enzyme
这个问题只是关于单元测试。
最近，我读了很多有关快照的内容，我真的很困惑，到底什么时候应该使用快照测试，而不是只使用显式断言。我使用react＆jest＆enzyme进行单元测试
据我了解，使用快照测试绝对有意义：检查组件是否按照我们预期的方式使用预期的 props 进行渲染。这样我们就不必为每个 prop 或渲染的每个组件等进行断言
问题：1）但是当涉及到模糊或点击等用户交互时，可能会有很多情况。在这种情况下，对每个测试用例进行快照有意义吗？假设我有 10 个不同的情况想要测试 onBlur。那么为此设置 10 个不同的快照有意义吗？我知道我们可以使用序列化器来过滤掉我们想要在快照上看到的内容，但不仅仅是使用单个断言进行常规数据驱动测试（其中包含开发人员提供的输入和预期输出）更好吗？
2）当我有一个组件依次渲染几个子组件并且这些子组件渲染它们的子组件等时怎么样。在这种情况下，我安装然后拍摄快照。这个快照变得非常巨大，我再次知道我们可以通过使用序列化器来调整它。但在这种情况下，快照到底有什么好处呢？
3) 一般来说，拥有太多快照不是一件坏事吗？
我还遇到了一些奇特的工具，例如 jest-glamor-react 等，它们可用于充分利用快照测试。但实际上，我如何确定哪种场景最适合使用快照进行测试，哪种场景最适合使用常规断言进行测试？我读了很多文章，但有些人对快照印象深刻，但这些示例非常基础。有些人完全反对它，并认为简单的旧断言更好。有人可以分享他们的观点吗？
为什么要进行快照测试？
无不稳定：因为测试是在命令行运行程序中运行，而不是在真实的浏览器或真实的手机上运行，所以测试运行程序不必等待构建、生成浏览器、加载页面并驱动 UI 来将组件放入预期状态往往不稳定并且测试结果变得嘈杂。
迭代速度快：工程师希望在不到一秒的时间内得到结果，而不是等待几分钟甚至几个小时。如果测试不像大多数端到端框架那样快速运行，工程师根本不会运行它们，或者一开始就不会编写它们。
调试：很容易进入 JS 中的集成测试代码，而不是尝试重新创建屏幕截图测试场景并调试视觉差异中发生的情况。
这是从这里得到的
现在回答你的问题：
当我必须跟踪 UI 元素时，我会使用快照测试，确保在没有故意进行更改的情况下不会发生任何更改。快照可以帮助您实现这一目标。