tdd-identify

一句话摘要

诊断当前时刻适合哪种 TDD 技巧——该采用 Beck 的哪种做法，取决于你是否知道要输入什么、测试是否太大、依赖是否太慢，或者你是否刚发现一个 Bug。

何时使用此技能

• 测试未通过，但你不确定如何让它通过。
• 你看得出实现应该是什么样，但不确定是直接输入代码，还是先造假再泛化。
• 你盯着下一个测试，却不知道该写哪一个。
• 测试碰到了缓慢或外部依赖，而你不确定如何隔离它。
• 你刚修复一个 Bug，却不确定该留下哪种测试。

何时不要使用此技能

• 你还没决定是否使用 TDD → 这是工作流问题，参见 tdd-red-green-refactor（如果已安装 Superpowers，也可参见 test-driven-development）。
• 你确切知道该用哪种技巧 → 直接使用相应技能。
• 看似是 TDD 问题，实则是领域建模问题 → 转到 ddd-design。

核心内容

按以下顺序，通过这些问题梳理你卡住的时刻：

1. 测试未通过，而你不知道该写什么代码？

• 我确切知道生产代码应该是什么样 → tdd-obvious-implementation。直接输入代码。
• 我知道这个特定输入的答案，但不知道通用算法 → tdd-fake-it。返回一个常量；让下一个测试推动你将其泛化。
• 我已经造了假，现在需要泛化 → tdd-triangulate。用不同的输入写第二个测试，让造假的实现无法通过。

2. 你要写的测试感觉太大了？

• 我看不出该如何为这个测试编写生产代码 → tdd-child-test。先把大测试放一边；写一个你能完成的较小测试；有了新的理解后再回来处理大测试。
• 我有一堆待写测试，不知道接下来该写哪个 → tdd-one-step-test。选择一个既能让你学到最多、又能快速实现的测试。

3. 测试碰到了缓慢、外部或不可靠的东西？

• 数据库、网络、文件系统、时间 → tdd-mock-object。使用测试替身；确保你也在某处针对真实对象进行测试。
• 测试单独运行时通过，一起运行时却失败 → tdd-test-isolation。每个测试都必须拥有自己的测试装置；不要共享可变状态。

4. 你正在使用一个不完全了解的第三方库？

• 我不确定这个库的行为；文档也不够充分 → tdd-learning-test。针对该库编写测试，以了解其行为，并发现升级导致的问题。

5. 你刚修复了一个 Bug？

• 每个 Bug 都要有测试 → tdd-regression-test。编写一个本可以捕获该 Bug 的测试；将它与修复一起提交。

6. 正在检查测试是否存在异味？

• 慢速测试、不稳定测试、相互依赖的测试、模拟自己不拥有的对象、测试框架而非自己的代码 → 使用 tdd-anti-patterns 进行审查。

决策启发

• Beck 本人的决策树（意译）：“如果你知道要输入什么，就直接输入（obvious-implementation）。如果不知道，但知道一个情况的答案，就用 fake-it。如果两者都不知道，就用 triangulate。如果还是卡住，那就去洗个澡。”
• 谨慎使用 mock-object。Mock 会让测试与实现耦合；只在边界处使用 Mock（外部服务、缓慢资源、时间）。
• 不确定测试规模时，始终选择 child-test——较小的测试能让你更快学到东西。

反模式

• 把每种技巧都当成“升级后就不再使用的阶段”。obvious-implementation 并不比 fake-it 更好；它们适用于不同的时刻。资深实践者会全部使用。
• 凭本能 Mock 一切。Mock 是最后的手段，不是默认做法。
• 修复后跳过 regression-test 步骤。Bug 会再次出现，而你没有任何测试可以捕获它。

另请参阅

• 此插件中的其他十一个 tdd-* 技能——以上每个分流都指向其中一个。
• Superpowers 的 superpowers:test-driven-development（如果已安装）——在工作流层面触发“现在使用 TDD”。

参考资料

• Kent Beck，《Test-Driven Development By Example》（Addison-Wesley，2002 年）——第 III 部分是经典的模式目录。
• Beck 本人关于 TDD 的“规则”文章和会议演讲。