TDD Done Right (TDD 的正确姿势)

这是一份关于“TDD 已死？”演讲的核心摘要。演讲者认为 TDD 本身没有问题，但业界普遍的实践方式已经偏离了其初衷，导致了诸多问题。以下是回归 TDD 本源思想的精华提炼。

核心要点（点击展开）

现代 TDD 实践的痛点

开发减速测试代码量远超生产代码（例如3倍），导致开发速度下降 20-50%。
测试脆弱测试与实现细节过度耦合，尤其是在大量使用 Mock 的情况下。代码一重构，大量测试就会失败，这违背了 TDD “保护重构”的核心承诺。
维护噩梦一段时间后，开发者（甚至是原作者）回头看测试，完全不明白其意图。当测试失败时，不知道是 Bug 还是实现已变更。
ATDD/BDD 陷阱像 FitNesse, Cucumber 这类工具编写的测试，客户很少真正关心，且运行缓慢，经常处于失败状态（“一片红”），最终沦为团队互相指责的根源。
核心观点：这些痛苦的根源在于，我们错误地将 TDD 的“单元”理解为“类/方法”，并开始为实现细节编写测试，而不是为软件行为。

回归 TDD 本源：测试行为，而非实现

改变触发点编写新测试的触发点不应该是“我要写一个新方法”，而应该是“我要实现一个新需求/行为”。
关注公开 API测试应该针对模块的公开契约 (Public API / Contract)，即它向外界承诺提供的功能。这些是稳定的。
隐藏内部实现模块内部的类、方法、结构都是实现细节，它们是不稳定的，可以随时为了优化而改变。不应该为它们编写独立的测试。
核心原则：Kent Beck 最初的“单元测试”中的“单元”，指的是一个模块 (Module)，而不是一个孤立的类。测试的隔离单位是“测试本身”，而不是“被测试的类”。
减少 Mock只在必要时使用 Mock，例如隔离外部昂贵资源（数据库、网络）或解决共享状态问题。绝对不要用 Mock 来隔离一个类和它的内部协作者。

正确地实践“红-绿-重构” (Red-Green-Refactor)

红 (Red) - 编写一个失败的测试

为即将实现的新行为编写一个测试。先运行它，确保它会因为功能未实现而失败。这是为了证明你的测试是有效的，而不是一个永远通过的“假测试”。
绿 (Green) - 快速让测试通过

用最快、最直接、甚至最“丑陋”的方式让测试变绿。这里的目标是验证解决方案的可行性，而不是追求完美的设计。可以硬编码、复制粘贴代码——此时，“速度压倒设计”。
重构 (Refactor) - 清理代码 (最关键的一步)

在测试保持绿色的前提下，清理刚刚写的“丑陋”代码。消除重复、改善命名、提取类和方法、应用设计模式。
至关重要：在重构阶段，不要添加任何新的测试！你唯一的测试就是第一步写的那个行为测试。所有内部实现（新类、新方法）都由这个高层级的行为测试来覆盖。这正是实现“测试与实现解耦”的关键。

架构的启示：端口与适配器 (六边形架构)

架构分离使用“端口与适配器”架构，将核心业务逻辑（领域模型）与外部基础设施（如 UI, 数据库, 消息队列）彻底分离。
核心领域 (Domain)内部是纯粹的业务逻辑对象 (POJOs/POCOs)，不依赖任何具体技术。
适配器 (Adapters)是与外部技术打交道的部分，例如一个处理 HTTP 请求的 Web Controller，或是一个操作数据库的 Repository 实现。
端口 (Ports)是核心领域定义的接口，是应用与外部世界通信的“插座”。
最佳实践：你的 TDD 测试应该针对“端口”进行。通过调用端口接口，验证整个核心领域的行为，而不是穿透到领域内部去测试单个类。这样你的测试就自然地成为了对“行为”的测试。
这能帮助你构建一个健康的“测试金字塔”，拥有大量快速、稳定的单元/开发者测试，而不是一个脆弱的“测试冰淇淋筒”。

总结与最终建议

测试行为，而非实现细节 - 这是最重要的原则。
拥抱“丑陋”的绿色阶段 - 先解决问题，再完善设计。
重构时绝不添加新测试 - 让实现自由演进。
让测试面向模块的“端口” - 从外部视角验证功能。
警惕过度 Mock 和 IoC 容器 - 它们常常是测试与实现耦合的重灾区。
最终结论：TDD 依然是强大而有效的实践。只要我们回归其初心——作为一种驱动设计和验证行为的工具，而不是一个检查每个实现细节的僵化规则——它就能带给我们高质量、易维护的软件。

原文