test-driven-development

测试驱动开发

TDD 铁律

先写代码，再写测试？删掉代码，重新开始。

这不容商量，也不是可选项。你无法为自己找理由来绕过这一点。

RED-GREEN-REFACTOR 循环

1. RED - 先编写一个失败的测试

• 编写最小的测试，确保它因正确的原因而失败
• 测试应该因为功能尚不存在而失败
• 运行测试并确认它失败

2. GREEN - 让测试通过（最少代码）

• 编写让测试通过所需的最少代码
• 不要编写不必要的代码
• 暂时不要优化
• 暂时不要重构

3. REFACTOR - 改进代码

• 现在可以清理代码了
• 消除重复
• 改进命名
• 提取方法／函数
• 重构后所有测试仍必须通过

禁止的自我辩解

如果你发现自己有以下任何想法，立即停下：

• “这只是一个简单的函数” → 错。简单函数也需要测试。
• “我之后再写测试” → 错。这不是 TDD。
• “让我先把它弄好再说” → 错。先写测试。
• “这个不需要测试” → 错。所有内容都需要测试。
• “我手动测试一下就行” → 错。编写自动化测试。
• “这个测试显而易见” → 错。照样写出来。
• “我只是在探索” → 错。用测试来探索。

测试质量指南

好的测试应当：

• 快速 - 测试应在几毫秒内运行
• 隔离 - 测试之间没有依赖
• 可重复 - 每次结果都相同
• 自我验证 - 通过或失败，无需解读
• 及时 - 在代码之前编写

测试结构（Arrange-Act-Assert）：

// Arrange - Set up the test conditions
const input = createTestInput();

// Act - Execute the code under test
const result = functionUnderTest(input);

// Assert - Verify the expected outcome
expect(result).toBe(expectedValue);

何时使用此技能

• 开始任何新功能时
• 修复任何 Bug 时（先编写一个能复现该 Bug 的测试）
• 重构现有代码时（先确保测试已存在）
• 任何可能破坏现有功能的代码变更

YAGNI（你不会需要它）

不要编写目前还不需要的代码：

• 不添加推测性功能
• 不创建“以防万一”的抽象
• 不要过早优化
• 只构建当前所需的内容，不多不少

DRY（不要重复自己）

但只在 REFACTOR 阶段进行：

• 先让它运行（GREEN）
• 再让它正确（REFACTOR）
• 暂时存在重复也没关系
• 在重构时消除重复

提交策略

• 每次 GREEN 后提交
• 每次 REFACTOR 后提交
• 小步、频繁提交
• 每次提交都应通过所有测试