Content

TDD（测试驱动开发）是一种通过编写测试来驱动软件设计的开发方法。其核心实践是“红-绿-重构”循环：首先编写一个会失败的测试（Red），然后编写最少的代码使其通过（Green），最后在测试保护下重构代码以改善设计。这种方法迫使开发者从接口和使用者的角度思考，而不仅仅是实现细节，从而产生更清晰、更可靠的代码。它与 YAGNI 原则紧密共生——TDD 确保所做的“最少之事”是可靠的，而 YAGNI 则防止为推测性需求编写多余的测试和代码。一些激进实践（如 Superpowers）甚至主张，如果无意中先写了实现代码，应将其删除再重新开始 TDD 循环，以避免测试被既有的实现细节所“污染”。

Acceptance

YoYo's Note

Question

1. 你目前的项目有多少测试覆盖？如果从零开始做 TDD，最大的阻力是什么？
2. Kent Beck 说”先写测试逼你先想接口”——你平时是先想接口还是先想实现？
3. Superpowers 说”先写了代码就删掉”，你能接受吗？沉没成本会不会让你犹豫？

See Also

YAGNI
Spec-First Development
Anti-Rationalization Pattern

Reference

• 2026-03-21-yagni-and-tdd
• Martin Fowler - TDD
• Kent Beck — Test Driven Development: By Example (2002)
• Superpowers test-driven-development skill

YoYo’s Note

TDD（Test-Driven Development）：先写测试，看到失败，再写最少代码让它通过，然后重构。

三步循环：RED（写失败测试）→ GREEN（写最少代码通过）→ REFACTOR（清理代码）

由 Kent Beck 在 1990 年代末作为极限编程的一部分发展。

两个核心收益

1. 自测试代码 — 只有让测试通过时才写生产代码，所以代码库天然有完整测试
2. 接口优先 — 先写测试 = 先想”我要怎么用这个功能” = 先设计接口

最大失败模式

忽略第三步 Refactor。只做 Red-Green 不重构 = 有测试的混乱代码。

和 YAGNI 的共生

• 没有 TDD 的 YAGNI = 灾难（代码不可靠，“以后再改”会炸）
• 没有 YAGNI 的 TDD = 浪费（为推测性功能写测试）
• 两者共同构成：做最少的事，但做得可靠

Superpowers 的激进立场

先写了代码？删掉。不当参考。删就是删。

因为后写的测试受实现偏见影响——你只测”做了什么”，不测”该做什么”。