核心要点

  • 红：先写一个会失败的测试，明确即将实现的最小行为

  • 绿：写刚好能让测试通过的最少代码，不提前优化

  • 重构：在测试保持绿色的前提下清理重复与坏味道

  • 小步快跑，每次只推进一个小需求，持续回归

标准回答

定义

TDD（Test-Driven Development）是一种「测试先行」的开发方法：在写实现代码之前先写测试，用测试来驱动设计与实现。

红-绿-重构循环

  • 红（Red）：写一个针对尚未实现功能的测试，运行它，它必然失败（红色）。这一步迫使你先想清楚「期望的行为和接口」。
  • 绿（Green）：用最简单、甚至「作弊」的方式写最少代码让测试通过（绿色），不追求优雅。
  • 重构（Refactor）：测试仍为绿色时，消除重复、改善命名与结构，由测试保证行为不变。
text
写失败测试 → 跑测试(红) → 写最少代码 → 跑测试(绿) → 重构 → 回到第一步

好处：天然形成回归测试网；测试即时反馈接口设计是否易用；测试用例充当可执行文档；小步推进降低调试成本。

常见误区

⚠️ 常见踩坑

TDD 不等于「事后补测试」或「追求 100% 覆盖率」；它的核心是用测试驱动设计与小步迭代，覆盖率只是副产品。

追问

追问 1：TDD 写不出测试时通常说明什么？

往往说明需求或接口边界还没想清楚，或被测单元职责过大、耦合过重难以隔离。这是 TDD 给出的设计反馈信号，应先拆分职责、引入依赖注入让其可测，而非跳过测试。

追问 2：TDD 和先写代码再补测试有何本质区别？

先写测试会从「使用者视角」设计接口，倒逼低耦合、可测的设计；事后补测试容易迁就已有实现、绕过难测路径，且常因赶进度被省略，测试沦为形式。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。

🎯 相关面试题