Snapshot Testing 实战指南：提升前端测试效率的关键技巧
シ智慧先跑个快照，再看它到底干了啥
上周重构一个老组件，改完后手动点了一遍所有页面，结果 QA 还是报了三个 UI 回退的 bug。我一拍脑袋：早该用 Snapshot Testing 了！这玩意儿真不是花架子，亲测有效。
别被名字吓到，Snapshot Testing（快照测试）其实就干一件事：把组件渲染出来的 HTML 或结构“拍张照片”存下来，下次跑测试时对比有没有变化。如果变了，就让你决定是“有意改动”还是“意外回退”。
最简单的用法，在 Jest + React 项目里一行代码搞定：
import React from 'react';
import { render } from '@testing-library/react';
import MyButton from './MyButton';
test('按钮快照', () => {
const { container } = render(<MyButton label="提交" />);
expect(container).toMatchSnapshot();
});第一次跑，会在 __snapshots__ 目录下生成 .snap 文件，内容长这样：
// MyButton.test.js.snap
exports[按钮快照 1] =
<div>
<button class="btn-primary">
提交
</button>
</div>
;下次你改了 MyButton 的类名、结构或者子元素，测试就会失败，并告诉你“快照不一致”。这时候你只要确认是不是你**故意**改的，如果是，按提示敲 u 更新快照就行。
这个场景最好用：UI 组件库 & 静态页面
我用得最爽的地方，就是写 UI 组件库。比如一个 Card 组件，支持 title、subtitle、actions 等一堆 props，手动测组合爆炸根本不可能。但快照测试能自动覆盖所有 render 结果。
举个例子，带 loading 状态的卡片：
// Card.test.js
import Card from './Card';
test('Card with loading', () => {
const { container } = render(
<Card
title="订单详情"
loading={true}
actions={<button>操作</button>}
/>
);
expect(container).toMatchSnapshot();
});只要 loading 为 true 时结构变了（比如加了个 spinner），测试立刻挂掉。比肉眼盯 UI 可靠多了。
另外，静态营销页、数据展示页这类“几乎不变”的页面，也适合用快照兜底。比如一个产品介绍页，改了文案或布局，快照能马上告诉你“你动了不该动的地方”。
踩坑提醒：这三点一定注意
快照测试好用，但坑也不少。我踩过至少五次，总结出三个必须注意的点：
- 别对含动态内容的组件直接快照。比如组件里用了
Date.now()、Math.random()或者从接口拿的用户 ID，每次跑测试快照都会变，导致误报。解决办法：mock 掉这些值。例如：
beforeEach(() => {
jest.spyOn(Date, 'now').mockImplementation(() => 1672531200000); // 固定时间戳
});
afterEach(() => {
jest.restoreAllMocks();
});- 快照文件别手动物改。
.snap文件是自动生成的，你手动改它等于欺骗测试。万一哪天回退了，你根本不知道。更新快照只用jest -u或交互式模式按u。 - 别把快照当唯一测试手段。快照只保证“和上次一样”，不保证“逻辑正确”。比如你把“删除”按钮的 onClick 事件删了，快照可能完全没变（因为结构没变），但功能已经崩了。所以快照要配合行为测试（比如 fireEvent.click + expect）一起用。
高级技巧：内联快照 + 自定义序列化器
有时候你不想搞一堆 .snap 文件，特别是测试逻辑简单、输出短的时候。Jest 支持 inline snapshot（内联快照），直接把快照写进测试文件里：
test('格式化金额', () => {
const result = formatCurrency(1234.56);
expect(result).toMatchInlineSnapshot("¥1,234.56");
});第一次跑会报错，但 Jest 会自动把快照值填进去（需要你用 VS Code 插件或命令行交互）。好处是快照和测试代码在一起，review 时一目了然。
另一个高级用法是自定义 serializer。默认快照会把整个 DOM 树 dump 出来，但有些属性（比如 data-testid、随机 class）你根本不关心。这时候可以写个 serializer 过滤掉：
// test/utils/stripRandomClasses.js
expect.addSnapshotSerializer({
test: (val) => val && val.$$typeof === Symbol.for('react.test.json'),
print: (val, print) => {
// 移除所有包含 "random-" 的 class
const cleanChildren = val.children?.map(child => {
if (typeof child === 'string') return child;
if (child.props?.className) {
child.props.className = child.props.className
.split(' ')
.filter(cls => !cls.startsWith('random-'))
.join(' ');
}
return child;
});
return print({ ...val, children: cleanChildren });
}
});然后在测试文件顶部引入，快照就干净多了。不过这招别滥用，serializer 写复杂了反而难维护。
别乱用：这些情况快照反而添乱
快照不是万能的。我见过有人给整个页面做快照，结果改个 footer 的版权年份，几十个测试全挂。这种大而全的快照，维护成本极高，建议拆成小组件粒度。
还有带复杂状态的组件，比如一个可折叠的菜单，展开/收起状态不同，快照也不同。这时候要么 mock 状态，要么干脆别用快照，改用断言具体 DOM 节点是否存在更靠谱。
另外，如果你的项目 UI 经常大改（比如初创公司 MVP 阶段），快照可能天天要更新，反而成了负担。这种时候，聚焦核心路径的行为测试更实用。
最后说两句
Snapshot Testing 本质上是个“变更检测器”，不是功能验证工具。用得好，能省下大量回归测试时间；用不好，就是一堆噪音。我的建议是：对稳定、结构化的 UI 组件启用快照，配合行为测试覆盖交互逻辑。
以上是我踩坑后的总结，希望对你有帮助。这个技巧的拓展用法还有很多（比如结合 Storybook 做视觉回归），后续会继续分享这类博客。有更优的实现方式欢迎评论区交流。
暂无评论