TDD(Test-Driven Development测试驱动开发)
TDD（Test-Driven Development，测试驱动开发）的核心思想是先写测试，后写实现代码，以极短的迭代周期推动软件设计。其标准流程即著名的 红 - 绿 - 重构（Red-Green-Refactor） 循环。
基本步骤
写一个失败的测试 (Red): 明确需求与接口设计.
根据当前需求编写一个极小的单元测试。此时被测试的代码尚未编写或仅有空骨架，运行测试时必须失败（通常标红），以此验证测试本身是有效的，避免“写了假测试”。用最快的方式让测试通过 (Green): 专注于功能的快速实现.
编写刚好能让该测试通过的最少生产代码。在此阶段不需要考虑代码架构和优雅度，甚至硬编码常量也是允许的，首要目标是让测试套件变绿。重构代码 (Refactor): 测试护航下的坏味道消除.
在已有绿色测试的保护下，优化代码设计：消除重复代码、提取公共方法、改善命名与结构。重构期间不新增任何外部功能，并确保每次改动后所有测试依然全部通过。重复循环 (Repeat): 小步快跑推进功能.
挑选下一个边界条件或细分需求，回到第一步继续编写新的测试，逐步构建出完整的系统。
核心三定律
- 除非是为了让一个失败的单元测试通过，否则不允许编写任何生产代码。
- 只能编写刚好能导致失败的单元测试（编译失败也算失败）。
- 只能编写刚好能让当前失败测试通过的生产代码。
落地优势与常见误区
| 维度 | TDD 带来的实际收益 | 常见误区 / 反模式 |
|---|---|---|
| 设计质量 | 强制先站在调用者视角思考 API，天然提高模块解耦性 | 测试过度关注内部私有实现细节，导致一改架构测试全挂 |
| 调试成本 | Bug 在产生瞬间被定位，大幅缩短排错时间 | 一次性写太多测试或过大功能，导致跳出短反馈循环 |
| 维护文档 | 测试用例本身即最新、最准确的可执行设计文档 | 在“绿”之后跳过重构步骤，导致技术债堆积 |