bash

1. 先运行快照测试，查看失败清单

jest --testPathPattern="UserProfile"

2. 逐一检查失败的快照差异，确认哪些是预期变更

3. 使用交互模式只更新合法的快照

jest --testPathPattern="UserProfile" --watch

在 watch 模式下按 'u' 更新当前失败用例的快照

在 CI 环境中，快照测试必须**永远不自动更新**。任何快照不匹配都应导致构建失败，强制开发者在本地审查差异后再提交更新。

### 策略二：对不稳定输出进行序列化控制

如果组件渲染了动态值（时间戳、随机 ID、第三方库生成的哈希类名），直接快照会造成每次运行都失败。解决方案是使用自定义快照序列化器 (`snapshotSerializers`) 或在测试中替掉动态部分。

#### 示例：消除动态时间戳
```javascript
// component.test.js
it('renders order time', () => {
  const order = { time: new Date('2025-01-01T00:00:00Z') };
  const tree = render(<OrderCard order={order} />);
  expect(tree).toMatchSnapshot();
});
// 快照中固定为可控的日期值

对于无法轻易模拟的值，可以通过 expect.addSnapshotSerializer 注册一个插件，将特定类型的值转换为稳定形式。

// snapshotSerializers/mockDate.js
module.exports = {
  test(val) {
    return val instanceof Date;
  },
  print(val) {
    return '"[MockDate]"';
  },
};

在 jest.config.js 或测试启动文件中引入：

{
  "snapshotSerializers": ["./snapshotSerializers/mockDate.js"]
}

策略三：细化断言，避免海量 HTML 快照

大型 DOM 快照是维护灾难的核心。一旦外层布局微调，波及数十个快照。用更具针对性的断言替代部分快照：

• 语义化查询：expect(screen.getByRole('alert')).toBeInTheDocument()
• 属性/内容快照：只快照关键片段，而非整个组件树。
• 内联快照：对于纯文本或简短值，toMatchInlineSnapshot() 会将快照嵌入测试文件，提升可读性并减少文件跳转。

// 差：全量 HTML 快照
expect(container).toMatchSnapshot();

// 好：精准断言关键部分
expect(screen.getByText('User: Alice')).toBeInTheDocument();
expect(screen.getByRole('button', { name: 'Delete' })).toBeDisabled();
// 若仍需快照，只捕获变化区域
expect(getByTestId('user-meta')).toMatchSnapshot();

策略四：定期清理废弃快照

未使用的快照不仅占用空间，还会让新成员误以为某些用例存在。利用 jest --prune 或在 CI 中加入检查：

# 删除所有与测试文件无关的过时快照
jest --prune

# 在 CI 中可以用 --detectOpenHandles 等，但 prune 建议作为本地定期任务

更好的做法是在提交钩子中提示开发者修剪快照，防止积累。

策略五：为快照维护建立明确的 Code Review 检查清单

在 Pull Request 阶段，评审者应关注以下几点：

• .snap 文件的变更行数是否与 PR 描述的功能修改规模匹配？
• 是否存在因测试数据未固定导致的波动性变更（如变动的 id、时间）？
• 快照中是否出现 undefined、null 等非预期输出？
• 是否可以通过更小的断言替代部分快照更新？

维护工具链配置

配置 @testing-library/jest-dom 扩展匹配器

更语义化的断言能减少对快照的依赖：

import '@testing-library/jest-dom';
expect(button).toBeDisabled();
expect(list).toHaveClass('active');