TDD测试驱动开发(Test-Driven Development)

TDD是一种软件开发方法：先写测试，再写实现代码，最后重构代码。核心思想是：先明确程序应该实现什么行为，再编写代码让这些行为得到满足，而不是先写完代码再补测试。

---

1.TDD的核心流程

TDD通常遵循一个循环，称为红-绿-重构（Red-Green-Refactor）。

• 红（Red）：先写测试
  编写一个描述预期行为的测试，此时功能代码还不存在，测试应该失败。

目的：确认测试确实能检测出功能缺失。

• 绿（Green）：编写最少的实现代码
  编写刚好能让测试通过的代码，不急于追求完美设计。

目的：以最小的实现满足当前需求。

• 重构（Refactor）：优化代码
  在不改变外部行为的前提下，改善代码结构、消除重复，并再次运行测试。

目的：保持代码整洁，同时确保原有功能没有被破坏。

红 → 绿 → 重构 → 下一个测试 → 循环

2.TDD与传统开发有什么区别

对比维度	传统开发（常见方式）	测试驱动开发（TDD）
开发顺序	先实现功能，再补测试	先写测试，再实现功能
需求理解	编码过程中逐步明确	先用测试明确预期行为
反馈时机	可能在开发后期发现问题	每个小步骤都能获得反馈
代码设计	可能一次性设计过多	从具体需求逐步演进
回归验证	取决于测试覆盖和执行习惯	通过持续运行已有测试验证改动

传统开发也可以有完善的自动化测试。两者最主要的区别是测试在开发流程中的先后顺序，以及测试对设计过程的驱动作用。

3.TDD有什么优缺点

主要优点

• 减少回归问题：修改代码后，可以通过已有测试发现意外破坏的功能。
• 明确需求：测试把抽象的需求转化为可验证的行为。
• 改善设计：为了让代码容易测试，开发者往往会设计出职责更清晰、耦合更低的模块。
• 提供可执行的文档：测试可以说明函数在不同输入下应该有什么结果。

主要缺点

• 前期投入更多：需要先编写和维护测试。
• 测试质量决定效果：测试本身可能遗漏重要场景，也可能错误地固化某种实现。
• 修改需求时需要维护测试：如果业务规则变化，相关测试也需要更新。
• 并非所有场景都容易测试：例如复杂的UI交互、视觉效果和涉及真实外部系统的行为，需要额外的测试策略。

4.什么时候适合使用TDD

场景	适用程度
业务规则、计算逻辑	非常适合
API接口、数据转换	非常适合
重构已有业务代码	适合，前提是有可靠的行为验证
算法和边界条件较多的模块	非常适合
纯视觉设计、探索性原型	不一定适合严格的TDD流程