name: test-driven-development description: 先写测试，看着它失败，编写最小代码使其通过 version: 3.2.0 category: testing author: Jesse Vincent license: MIT source: https://github.com/obra/superpowers-skills/tree/main/skills/testing/test-driven-development progressive_disclosure: entry_point: summary: “通过严格的RED/GREEN/REFACTOR循环强制测试优先开发。永远不要在失败测试之前写实现代码。” when_to_use: “在实现任何功能或bug修复时，在写实现代码之前。总是用于新功能、bug修复、重构和行为更改。” quick_start: “1. 写失败测试 2. 看着它失败（验证） 3. 编写最小代码使其通过 4. 看着它通过（验证） 5. 如果需要，重构 6. 重复” references: - workflow.md - examples.md - philosophy.md - anti-patterns.md - integration.md context_limit: 800 tags:

tdd
testing
red-green-refactor
test-first

测试驱动开发 (TDD)

概述

先写测试。看着它失败。编写最小代码使其通过。

核心原则： 如果你没有看着测试失败，你就不知道它是否测试了正确的东西。

此技能通过遵循RED/GREEN/REFACTOR循环强制严格的测试优先开发。违反规则的文字就是违反规则的精神。

何时使用此技能

总是：

新功能
Bug修复
重构
行为更改

例外（询问人类伙伴）：

临时原型
生成的代码
配置文件

想着“跳过TDD就这一次”？停止。这是合理化。

铁律

没有失败测试前，不写生产代码

在测试前写代码？删除它。重新开始。

没有例外：

不要保留它作为“参考”
不要在写测试时“适应”它
删除意味着删除

核心原则

RED：先写失败测试
GREEN：编写最小代码使测试通过
REFACTOR：在保持测试绿色的同时改进代码
NEVER：在测试前写实现

快速开始

RED/GREEN/REFACTOR 循环

RED → 验证 RED → GREEN → 验证 GREEN → REFACTOR → 重复

RED：写一个最小测试显示期望行为
验证 RED：运行测试，确认它因正确原因失败
GREEN：编写最简单的代码使测试通过
验证 GREEN：运行测试，确认它通过
REFACTOR：清理同时保持测试绿色
重复：下一个测试用于下一个功能

循环详情

RED：写一个最小测试（一个行为，清晰名称，真实代码） 验证 RED：强制 - 看着它因正确原因失败 GREEN：编写最简单的代码通过（无额外） 验证 GREEN：强制 - 看着它通过，所有测试通过 REFACTOR：清理同时保持测试绿色（可选）

关键提醒

总是在实现前写测试
让每个测试先失败以验证它测试了某些东西
保持实现最小 - 仅足以通过测试
仅在测试绿色时重构
一次一个循环 - 小步骤
如果测试立即通过，它没有测试新行为

红旗 - 停止并重新开始

如果你发现自己：

在测试前写代码
测试立即通过
无法解释为什么测试失败
“我会测试后”
“保留作为参考”
“已经花了X小时，删除是浪费”
“测试后达到相同目的”

所有这些意味着：删除代码。用TDD重新开始。

为什么顺序重要

测试后立即通过（证明不了什么），测试先失败然后通过（证明它有效）。详见哲学。

与其他技能的集成

系统化调试：在阶段4创建失败测试（bug复现）
完成前验证：验证测试存在并看着它们失败
深度防御：在实现功能后添加验证测试

现实影响

从TDD实践：

测试优先：95%+ 首次正确性
测试后：40% 首次正确性
TDD时间：每个功能25-45分钟（包括测试）
非TDD时间：15分钟编码 + 60-120分钟调试

TDD是实用的 - 在提交前找到bug，防止回归，记录行为，启用重构。

测试驱动开发Skill test-driven-development