misonl TDD（测试驱动开发）工作流
先写测试，后写代码。
1. TDD 核心循环
[CRITICAL] 红（RED）-> 编写一个失败的测试
v
[NIT] 绿（GREEN）-> 编写最少量的代码使测试通过
v
重构（REFACTOR）-> 优化代码结构与质量
v
循环往复...
2. TDD 三大法则
- 除非是为了使一个失败的单元测试通过，否则不允许编写任何生产代码。
- 只允许编写刚好能够证明失败的测试（编译失败也算失败）。
- 只允许编写刚好能够使当前失败测试通过的生产代码。
3. “红（RED）”阶段准则
编写重点
| 关注点 | 示例 |
|---|---|
| Behavior（行为） | “应当能够相加两个数字” |
| Edge Cases（边缘情况） | “应当能够处理空输入” |
| 错误状态 | “遇到无效数据时应当抛出异常” |
“红”阶段规则
- 测试必须先失败。
- 测试名称应清晰描述预期的行为。
- 每个测试（最好）仅包含一个 Assertion（断言）。
4. “绿（GREEN）”阶段准则
最少代码原则
| 原则 | 含义 |
|---|---|
| YAGNI | You Aren't Gonna Need It（你不会需要它） |
| 最简方案 | 编写能让测试通过的最少代码 |
| 暂不优化 | 此时只求“跑通”，不求“精炼” |
“绿”阶段规则
- 不要编写多余的代码。
- 暂时不要进行性能优化。
- 仅仅是为了通过测试，不多做一点。
5. “重构（REFACTOR）”阶段准则
优化方向
| 领域 | 动作 |
|---|---|
| 重复逻辑 | 提取公共函数/代码块 |
| 命名规范 | 使代码意图更加清晰 |
| 代码结构 | 改善组织架构 |
| 复杂度 | 简化逻辑判断 |
重构规则
- 所有测试必须保持绿色。
- 采取小步快跑的增量式改动。
- 每次重构之后都进行 Commit（提交）。
6. AAA 模式
每个测试均应遵循 AAA（Arrange-Act-Assert，准备-执行-断言）：
| 步骤 | 目的 |
|---|---|
| Arrange（准备） | 初始化测试数据与环境 |
| Act（执行） | 执行被测代码逻辑 |
| Assert（断言） | 验证结果是否符合预期 |
7. 何时使用 TDD
| 场景 | TDD 价值 |
|---|---|
| 新功能开发 | 极高 |
| Bug（缺陷）修复 | 极高（先写复现测试） |
| 复杂逻辑实现 | 极高 |
| Spike（探索性研究） | 较低（研究完后再补 TDD） |
| UI（用户界面）布局调试 | 较低 |
8. 测试优先级
| 优先级 | 测试类型 |
|---|---|
| 1 | Happy path（正常路径） |
| 2 | Error cases（错误处理） |
| 3 | Edge cases（边界情况） |
| 4 | Performance（性能） |
9. 应避免的反模式
| [FAIL] 禁止（Don't） | [OK] 推荐（Do） |
|---|---|
| 跳过“红”阶段直接写代码 | 亲眼见证测试失败后再写代码 |
| 先写代码后补测试 | 先写测试作为规格说明 |
| 初期就进行过度工程 | 保持简单，仅满足当前测试 |
| 一个测试包含过多断言 | 每个测试仅验证一个行为 |
| 测试内部实现细节 | 测试对外的行为表现 |
10. AI 增强型 TDD 协作模式
Multi-Agent（多智能体）编排视角
| Agent | 角色 |
|---|---|
| Agent A | 编写失败测试（RED） |
| Agent B | 编写实现使其通过（GREEN） |
| Agent C | 进行优化（REFACTOR） |
记住： 测试就是规格。如果你写不出测试，说明你还没有真正理解需求。