快照测试基础

说到快照测试，我印象特别深。刚接触前端项目那会儿，有个同事改了个全局样式，结果十几个页面的按钮全变样了，测试还没发现。上线后被用户骂惨了。后来我们引入了快照测试，这种问题基本就绝迹了。

你可能会问，快照测试到底是什么？为什么它能抓到这种回归问题？

说白了，快照测试就是给 UI 组件拍一张「照片」，然后拿它跟之后的每次拍摄做对比。如果哪次组件渲染出来的东西不一样了，测试就会报红。这个机制很朴素，但特别管用。

什么是快照测试

快照测试的核心思路就三步：

1. 录制基线 – 第一次运行测试时，把组件渲染的结果（DOM 结构、序列化后的文本等）存成一个文件，这就是「快照」。
2. 执行对比 – 后续每次跑测试，重新渲染组件，再把新结果跟之前的快照文件做 diff。
3. 报告差异 – 如果完全一致，测试通过；如果不一致，测试失败，并亮出哪里变了。

// Button.snap
// Jest Snapshot v1, https://goo.gl/fb4XNvX

exports[`Button renders correctly 1`] = `
<button
  className="btn btn-primary"
  disabled={false}
  type="submit"
>
  Submit
</button>
`;

为什么叫「快照」？就是因为它只记录「那一刻」的样子。你想想看，UI 组件的行为很多时候就是「给定 props，输出结构」。快照测试正好验证这个输出有没有悄悄变化。

我遇到过最典型的场景：一个团队并行开发，A 同事改了全局 CSS 变量，B 同事的组件覆盖了某个颜色。传统的单元测试根本测不到这种视觉回归，但快照测试会在下一次 CI 运行时直接报出 DOM 差异。嗯，这就是它的价值。

快照测试在 UI 回归中的作用

UI 回归测试要解决的核心问题就一个：代码改了，UI 有没有被意外弄坏？

手动测？太慢了，而且人眼容易疲劳。断言测试？它只能检查「某个元素的文字是否为预期」，但管不了整体布局和样式有没有跑偏。

快照测试在这块的作用很明确：

• 捕获意外变更 – 任何非预期的结构/样式变化都会被标记出来。
• 提供快速反馈 – 在 CI 里几秒钟就能跑完几百个快照，比截图对比快得多。
• 强制人工审核 – 当快照失败时，开发者必须确认：「是我有意改的，还是不小心改坏的？」如果是期望的修改，就更新快照；否则就是 bug。

我记得有一次重构组件的 API，把 prop variant 从字符串改成了对象。有几个地方沿用旧写法，传进来的是 variant="primary"，但新组件只认 variant={{ kind: "primary" }}。结果这些页面渲染出来什么都不显示。快照测试第一时间就抓到了，因为渲染结果从 DOM 变成了 null。要是没有这个防线，上线后就得热修复。

快照测试与断言测试的区别

很多新手会把快照测试和断言测试混为一谈。其实它们关注的层面完全不同。我画了一张对比表格，你看完就明白了。

维度	快照测试	断言测试（如 expect、should）
检查对象	整体渲染输出（DOM、JSON、序列化字符串）	具体的值、属性、行为
粒度	粗粒度，覆盖全量结构	细粒度，精确定位某部分内容
变更检测手段	字符串/对象 diff	显式比较（toEqual、toHaveLength 等）
维护成本	初期低，但频繁更新快照会增加 review 负担	需要手动写每个断言，但变更时修改范围明确
典型使用场景	验证页面布局、组件渲染结构	验证数据运算结果、事件回调是否触发

你看，快照测试适合「我不关心具体数值，只要整体没乱变」的场景；而断言测试适合「我一定要保证这个值等于 42」的场景。两者互补，不是替代关系。

我个人习惯：每个重要组件都配一个快照测试，用于守护 UI 的整体结构；然后在关键逻辑处再写几条断言测试，卡住核心数据流。

举个例子。一个用户头像组件，快照测试可以验证：头像地址、默认占位、加载状态、错误状态……全部结构是否正确。断言测试则只需要验证：当 props.src 为空时，是否渲染了默认图标。快照把大面罩住了，断言把关键点锁死。

你可能会担心快照文件太多，影响仓库大小。其实，.snap 文件本质上是纯文本，体积很小。一个中等规模的项目，几百个快照加起来也就几百 KB，比一张截图都小。

本章知识体系

下面这张图把本章的核心逻辑串起来了。你可以用它作为参考，快速回顾快照测试在整个回归测试链中的位置。

总结一下：快照测试是 UI 回归的守门员，它不关心业务逻辑对错，只关心「样子变了没」。结合断言测试，就能构建出一套兼顾整体和细节的自动化测试体系。