test-driven-development

Test-Driven Development (TDD)

技能概述

在编写实现代码之前先编写测试的开发方法论，通过"红-绿-重构"循环确保代码质量并防止回归。

适用场景

新功能开发

在实现任何新功能时，首先编写失败的测试来定义预期行为，然后编写最少代码让测试通过。这确保代码从一开始就有测试覆盖，并且接口设计符合实际使用需求。

Bug 修复

修复 bug 时先编写能重现问题的失败测试，确保修复后问题不会再次出现。测试充当回归保护，防止相同 bug 在未来被重新引入。

代码重构

在有测试保护的前提下进行代码清理和优化。测试套件作为安全网，让你可以自信地改进代码结构，而不必担心破坏现有行为。

核心功能

红-绿-重构循环

TDD 的核心三步流程：先写一个失败的测试（红），编写最少代码让它通过（绿），然后清理和改进代码（重构）。每个循环都保持测试通过，确保代码始终处于可工作状态。

验证驱动开发

强制开发者观看测试失败，确认测试真正测试了预期行为而不是测试了错误的实现。这防止了"测试通过但功能错误"的常见陷阱。

防御性编程指南

提供 TDD 使用的边界指导（何时使用、何时例外），并帮助识别常见的合理化借口和危险信号，防止团队滑向"先写代码后补测试"的反模式。

常见问题

什么是 TDD 的核心原则？

核心原则是"没有失败测试就不写生产代码"。这确保每行代码都是为了满足某个明确的需求而编写，并且有自动化测试保护。如果你没有看到测试失败，就无法确认它真的测试了正确的东西。

TDD 会降低开发速度吗？

短期来看可能感觉更慢，但长期来看更快。TDD 减少了调试时间（bug 在引入时就被发现），消除了回归测试的手动工作，并让重构变得安全。与其花数小时调试生产环境问题，不如花几分钟写测试。

什么时候不应该使用 TDD？

TDD 适用于所有功能代码和 bug 修复。例外情况需要与团队商议：一次性原型、自动生成的代码、配置文件。但要注意，"这次跳过"的想法往往是合理化的借口——一旦开始破例，很容易形成习惯。