# Zc Test Driven Development

> 测试驱动开发

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

---


# 测试驱动开发

## 角色定位

先用测试定义期望行为，再写最小实现让测试通过。这个 skill 负责行为变更的证据闭环，不负责铺满测试理论或替代专项浏览器 QA。

## 何时使用

- 新增或修改可观察行为。
- 修复 bug，需要先复现再修复。
- 重构可能影响现有行为。
- 需要为边界条件、错误路径或兼容性补回归保护。

不适用：纯文档、纯静态内容、无行为影响的配置调整。浏览器体验改动需要再接 `browser-qa-testing`。

## 快速路径

1. 写清要证明的行为或 bug 症状。
2. 选择最小测试层级：unit / integration / E2E。
3. **RED**：先写一个会失败的测试，确认失败原因匹配目标。
4. **GREEN**：写最小实现，只让当前测试通过。
5. **REFACTOR**：在测试保持绿色的前提下简化实现。
6. 跑相关回归测试，确认没有破坏邻近行为。
7. 记录测试证据和仍未覆盖的风险。

## Bug 修复 Prove-It 模式

```text
Bug report -> Reproduction test fails -> Fix -> Reproduction test passes -> Regression suite passes
```

如果无法先写复现测试，必须说明原因，并给出替代证据，例如最小命令、日志、浏览器 transcript 或人工可复查步骤。

## 测试层级选择

| 层级 | 何时选 | 代价 |
|---|---|---|
| Unit | 纯逻辑、边界判断、数据转换 | 快，信心局部 |
| Integration | API、数据库、文件系统、模块边界 | 中等，能发现契约问题 |
| E2E / Browser | 用户关键路径、前端集成体验 | 慢，但最接近真实用户 |

默认从能证明目标的最低成本层级开始。不要为了形式写高层测试，也不要用过度 mock 让测试只证明实现细节。

## 测试质量门禁

- 测试名字描述行为，而不是实现细节。
- 断言结果状态，少断言内部调用顺序。
- 测试数据最小且可读，优先 DAMP 而不是过度 DRY。
- mock 只用于慢、不可控或有副作用的外部依赖。
- 每个测试失败时应指向一个清晰原因。

写复杂断言、mock 或测试 helper 前，读取 `references/high-signal-tests.md`，先命名测试要捕获的真实 break，并做独立期望与 mutation check。

## 反模式

- 先写实现，再补一个永远会过的测试。
- 修改测试来迁就错误实现。
- 跳过失败测试继续加功能。
- 用快照覆盖大量不稳定 UI，导致 diff 不可审。
- 为了覆盖率写不验证业务行为的测试。

## 输出契约

```text
TDD evidence:
- Behavior:
- Test added/changed:
- Red result:
- Green result:
- Regression command:
- Remaining risk:
```

推荐结论使用：

```text
Recommendation: <继续实现 / 修复测试 / 补更高层验证 / 进入 review> because <测试证据、风险和被放弃替代方案>。
```

没有读过失败输出和通过输出，不要声明测试闭环成立。