kscz0000 测试驱动开发工作流
先写测试，再写代码。
1. TDD 循环
🔴 RED → 编写失败的测试
↓
🟢 GREEN → 编写最少代码使测试通过
↓
🔵 REFACTOR → 改进代码质量
↓
重复...
2. TDD 三定律
- 只为让失败测试通过而编写生产代码
- 只编写刚好能展示失败的测试
- 只编写刚好能让测试通过的代码
3. RED 阶段原则
编写内容
| 重点 | 示例 |
|---|---|
| 行为 | "should add two numbers" |
| 边界情况 | "should handle empty input" |
| 错误状态 | "should throw for invalid data" |
RED 阶段规则
- 测试必须先失败
- 测试名称描述预期行为
- 每个测试一个断言（理想情况）
4. GREEN 阶段原则
最少代码
| 原则 | 含义 |
|---|---|
| YAGNI | 你不会需要它 |
| 最简实现 | 写最少代码通过测试 |
| 不做优化 | 只需能跑通 |
GREEN 阶段规则
- 不写多余的代码
- 暂不优化
- 通过测试即可，不多不少
5. REFACTOR 阶段原则
改进方向
| 方面 | 行动 |
|---|---|
| 重复代码 | 提取公共代码 |
| 命名 | 让意图清晰 |
| 结构 | 改善组织方式 |
| 复杂度 | 简化逻辑 |
REFACTOR 规则
- 所有测试必须保持绿色
- 小步增量修改
- 每次重构后提交
6. AAA 模式
每个测试遵循：
| 步骤 | 目的 |
|---|---|
| Arrange | 准备测试数据 |
| Act | 执行被测代码 |
| Assert | 验证预期结果 |
7. 何时使用 TDD
| 场景 | TDD 价值 |
|---|---|
| 新功能 | 高 |
| Bug 修复 | 高（先写测试） |
| 复杂逻辑 | 高 |
| 探索性开发 | 低（先探针，再 TDD） |
| UI 布局 | 低 |
8. 测试优先级
| 优先级 | 测试类型 |
|---|---|
| 1 | 主路径 |
| 2 | 错误情况 |
| 3 | 边界情况 |
| 4 | 性能 |
9. 反模式
| ❌ 不要 | ✅ 应该 |
|---|---|
| 跳过 RED 阶段 | 先观察测试失败 |
| 事后补测试 | 先写测试 |
| 过度设计 | 保持简单 |
| 多个断言 | 每个测试一个行为 |
| 测试实现细节 | 测试行为 |
10. AI 增强 TDD
多智能体模式
| 智能体 | 角色 |
|---|---|
| 智能体 A | 编写失败测试（RED） |
| 智能体 B | 实现代码通过（GREEN） |
| 智能体 C | 优化代码（REFACTOR） |
记住： 测试就是规范。如果你写不出测试，说明你还没理解需求。
适用场景
本技能适用于执行概述中描述的工作流或操作。
限制
- 仅在任务明确匹配上述范围时使用
- 不要将输出视为环境特定验证、测试或专家评审的替代品
- 缺少必要输入、权限、安全边界或成功标准时，停下来请求澄清