# Antd Test Review

> 审查 ant-design 测试用例是否值得保留。在用户要求验证测试 case、review 测试质量、判断测试是否合理、是否“用 A 证明 A”、是否重复、是否锁定实现细节，或决定测试应删除、保留还是改写时使用。

- Skill: `ant-design/antd-test-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ant-design/antd-test-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ant-design/antd-test-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ant-design (https://skillmd.com/u/ant-design)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ant-design/antd-test-review

---


# Ant Design 测试用例审查

## 目标

一、只判断测试用例是否合理，不负责创建或补充测试。

二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。

三、验证场景默认只做静态审查，不默认运行测试。

四、输出先给结论，再给最关键原因。

## 何时使用

当用户提到以下意图时使用此 skill：

- 验证测试 case
- review 测试是否合理
- 判断测试是否无意义
- 判断测试是否重复
- 判断测试是不是“用 a 证明 a”
- 决定测试应保留、改写还是删除

## 不做的事

- 不主动新增测试
- 不主动补回归测试
- 不主动修改生产代码
- 不默认执行 `npm test`、`npm run test:update`

如果用户明确要求“顺手给改写建议”，可以在结论后补一句改写方向；但主任务仍然是审查，不是落地实现。

## 核心判断

### 一、先看契约是否独立

先用一句话描述这条测试声称在保护什么：

`当 <前置条件> 时，<组件/方法> 应该 <可观察结果>。`

如果这句话只能从当前实现反推出来，这条测试大概率不值得保留。

### 二、expected 必须来自独立来源

高质量来源包括：

- issue / PR 里明确描述的回归现象
- 组件文档、API、demo、FAQ
- DOM / React / WAI-ARIA / 浏览器语义
- 用户可感知的文本、属性、交互、布局结果

低质量来源包括：

- 生产代码里的同一个 helper、token、常量、分支逻辑
- 在测试里复制一遍实现
- “因为实现可能要这样写，所以我断言它这样写了”

### 三、优先审查外部行为，不审查实现细节

优先级：

1. DOM / 文本 / 属性 / role / aria
2. callback 的触发与参数
3. 用户或使用方能观察到的行为结果
4. 只有存在独立契约时，class / style 才能作为代理信号

如果断言锁定的是具体 CSS 属性、临时 class、内部状态或中间过程，默认先判低价值。

### 四、默认拦截样式实现自证

以下写法默认按“无实际作用”或“需要改写”处理，除非能证明它对应公开契约：

- `toHaveStyle(...)`
- `toHaveClass(...)`
- 断言具体 CSS 属性、CSS 变量、临时 class 存在

典型反例：

- `expect(node).toHaveStyle({ whiteSpace: 'nowrap' })`

如果它只是验证“实现里加了 `nowrap`”，而不是验证独立可感知行为，就属于“用 A 证明 A”。

### 五、重复覆盖也应判低价值

以下情况优先判为重复或冗余：

- 已有 `mountTest`、`rtlTest` 或其他聚焦行为测试覆盖相同契约
- 同一组件已有相同 props 组合和同类断言
- 新 case 只是换文案、换变量名、换写法，没有新增行为分支

## 输出要求

默认只输出最终结论，不写调研过程。

格式：

```text
结论：此用例无实际作用 / 此用例可保留 / 此用例需要改写
原因：
- ...
- ...
```

规则：

- 先下结论，再给原因
- 原因保留 2 到 4 条即可
- 不要先讲命令、搜索过程、推理链
- 除非用户追问，否则不要展开长篇建议

## 执行流程

### 1. 静态审查优先

当用户是在验证测试是否合理时：

- 默认只读代码、diff、文档、demo、已有测试
- 默认不运行测试
- 不把“能不能跑过”当成主要判断依据

只有用户明确要求“跑一下”“验证 red/green”时，才执行测试命令。

### 2. 提炼被保护的契约

先回答：

- 这条测试到底想保护什么公开行为？

如果回答不稳，优先判为：

`结论：此用例无实际作用。`

### 3. 查独立依据

从以下位置找证据：

- 当前 PR / issue 描述
- 组件文档与 demo
- 现有测试
- 外部语义规范

如果找不到独立依据，而 expected 又来自实现本身，直接判低价值。

### 4. 查是否重复

需要时搜索现有覆盖：

```bash
rg -n "<关键字>|<issue号>|<行为描述>" components/<component> tests
```

如果同一契约已经被保护，新 case 通常应判为冗余。

### 5. 给出分类结论

分类标准：

- `此用例可保留` 条件：契约独立、断言面向外部行为、不是重复覆盖
- `此用例需要改写` 条件：测试意图可能对，但断言方式锁定实现或证据不足
- `此用例无实际作用` 条件：expected 同源、实现自证、重复覆盖、只测存在性、只测内部细节

## Ant Design 约束

- `__tests__` 中引用仓库内代码时使用相对路径
- 优先沿用目标组件现有测试结构与 helper
- 对样式问题，先问“能否用更外层行为表达”，再接受 style/class 断言

## 快速拦截

以下情况默认直接质疑：

- 输入 `a`，expected 也从同一路径算出 `a`
- 断言私有 helper / hook / 中间 state
- 断言 `className`、`whiteSpace`、`display`、`zIndex` 等具体实现
- 在已有 `mountTest`、`rtlTest` 旁边再补同类 case
- 只做 `toBeTruthy()` / `toBeDefined()` 这类存在性断言