第2节：快照测试简介
各位好，欢迎来到第二讲。今天咱们聊聊快照测试——一个看起来简单、用起来真香的技术。我第一次接触这个，是几年前维护一个老项目，每次改一行 CSS 都要手动点十几个页面确认样式没崩。后来团队引入快照测试，我才发现原来很多重复劳动是可以交给机器的。
说白了，快照测试就是把你代码的输出结果“拍个照”存起来，下次跑测试的时候再拍一张，对比两张照片是不是一样。不一样就说明有变化——可能是 bug，也可能是你故意改的。嗯，就是这么直观。
什么是快照测试
快照测试是一种自动化测试方法。它不加“断言逻辑”，而是直接记录输出结果的全部或部分内容，就像拍照一样。通常这个“照片”会序列化成字符串或文件（比如 JSON、HTML 片段），存在项目仓库里。
我用过一个叫 Jest 的测试框架，它集成了快照功能。第一次跑测试时，它会生成一个 .snap 文件。之后每次跑测试，都会拿当前输出和这个文件对比。你想想看，这比手写一堆 expect(x).toBe(y) 省事多了，尤其是当你只想确保结构不变时。
// 一个最简单的例子（伪代码）
test('组件渲染正确', async () => {
render(<MyComponent />);
expect(screen.getByRole('main')).toMatchSnapshot();
});
第一次执行这条测试，Jest 会生成快照文件。第二次再跑，它就会对比。如果没有任何变化，测试通过。如果有变化，测试失败，并告诉你差异在哪。
这里要注意：快照不是“断言正确性”，而是“断言不变性”。换句话说，它不保证你的逻辑是对的，只保证它没变过。
为什么需要快照测试
很多团队刚接触快照测试时会问：“有这个必要吗？不是已经有单元测试和集成测试了吗？” 我的答案是：有必要。它解决的是几个实际痛点：
- 防止意外回归： 改了一个共享组件，结果几个页面都变样了。手工测试很难覆盖全，快照测试能第一时间发现。
- 快速反馈： 我习惯在每次提交前跑一遍快照，几秒钟就知道有没有不该变的东西变了。比等人工 review 快多了。
- 充当“活的文档”： 快照文件就是一份自动生成的最新输出记录。新同事看代码时，翻翻快照就知道这个组件大概长什么样。
- 降低测试编写成本： 不需要逐字段写断言，尤其是嵌套很深的对象或 DOM 树。Jest 帮你自动生成基线。
| 场景 | 传统测试方式 | 快照测试方式 |
|---|---|---|
| UI 组件结构 | 写多个断言检查标题、按钮、列表项 | 一次快照捕获整个 DOM 树 |
| API JSON 响应 | 检查每个字段类型和值 | 快照对比整个 JSON 结构 |
| 配置文件输出 | 手动 diff 文件 | 自动快照对比 |
| 数据序列化结果 | 写 assert 比较字段 | 快照整体对比 |
当然，快照测试不是银弹。它的主要问题是“噪声敏感”——一个时间戳或随机ID都会导致测试失败。你需要做好数据清理或 mock。我曾经因为没处理日期字段，快照测试每次跑都失败，排查了半天才发现是服务器返回的时间戳每次都不一样。从此我养成了习惯：凡是动态字段，先 mock 掉。
适用场景
快照测试不是万能的，但有好几个场景特别适合。我挑三个最常见的说：
1. UI 组件
这是最经典的应用。渲染一个 React/Vue/Angular 组件，把生成的 DOM 结构存为快照。每次改动后对比，可以快速发现 DOM 结构变化。比如你重构了某个按钮的 class，快照直接告诉你多了一个 btn-outline 类。你想想看，这比肉眼逐个页面检查靠谱多了。
2. API 响应
有些接口返回的 JSON 结构很复杂，手写断言又累又容易漏。快照测试可以把一次请求的完整响应体拍下来，下次请求时自动对比。我记得上一个项目，后端改了某个字段的命名，快照测试第一时间报红，我们才发现适配器没更新——幸好有快照，否则上线才发现就晚了。
用代码举个简单例子：
test('GET /users 返回用户列表', async () => {
const response = await request(app).get('/users');
expect(response.body).toMatchSnapshot();
});
3. 配置文件
无论是 .env 模板、docker-compose.yml 还是 webpack.config.js 的序列化输出，快照都能帮你捕捉变化。尤其是 CI 流程中自动生成的配置文件，快照可以确保每次构建生成的配置是一致的。
其他适用场景还包括：代码生成器输出、markdown 转 HTML 结果、SQL 查询结果序列化等等。只要输出是可预测的、可序列化的，都可以考虑用快照测试。
工作流程概览
下面这张 SVG 图展示了快照测试从生成到对比的完整流程。我在每个节点上都标注了常见的“坑”和“做法”，你可以把它当作一个速查图。
--updateSnapshot 一键更新基线。这样既能保证覆盖率，又不浪费大量时间在写断言上。不过要记住：别盲目更新，每次更新前看一眼 diff。
好了，以上就是快照测试的基本概念、作用以及适用场景。它是自动化测试工具箱中一把趁手的小刀——轻量、直接、好用。下节我们会深入 GitHub Actions 的具体集成方案，看看怎么把这些知识落地到 CI 流水线里。