TDD 与单元测试：用测试驱动设计与反馈

TDD 不是“先写测试”这么简单，而是把设计反馈压缩到很短的循环里。测试先描述期望行为，代码再满足这个行为，最后通过重构改善结构。

核心循环

stateDiagram-v2
    [*] --> Red
    Red: 写一个失败测试
    Red --> Green: 写最小实现
    Green --> Refactor: 测试通过后整理设计
    Refactor --> Red: 下一个行为

实际工程场景

当业务规则包含边界条件、状态迁移、金额计算或权限判断时，TDD 可以帮助你先澄清行为，再写实现。它尤其适合领域服务、值对象和纯业务规则。

常见误区

• 为了覆盖率写脆弱测试。
• 只测实现细节，不测业务行为。
• 测试太大，失败时无法定位原因。

最佳实践

• 每个测试只表达一个业务行为。
• 命名中体现 Given / When / Then。
• 重构必须发生在绿灯之后。
• 对外部依赖用契约或集成测试补足。