tdd：测试驱动开发

tdd：测试驱动开发

tdd 是模型触发的测试驱动开发技能：用一个行为一个行为的红-绿-重构循环把功能或修复「逼」出来。它只测预先约定的公共接缝，杜绝实现耦合与同义反复测试。可单独用，也被 implement 内部调用。

红绿循环的最佳实践：一次只写一个测试，先红后绿，绝不批量铺测试。

它解决什么问题

代理写测试常犯两个错：要么批量写一堆想象中的测试（横切），要么测内部实现、写成同义反复。这样的测试既脆弱又没用。

何时使用

• 要测试先行地构建一个具体行为
• 要修一个 bug 并先用测试锁住
• 强调测试能在重构后依然存活

核心工作流

关键原则与反模式

• 垂直切片，不要水平切片：一次一个测试→一点实现，而非先写全部测试
• 只测预先约定的公共接缝（seam），不测内部
• 好测试读起来像规格（如「有效购物车能结算」），重命名内部函数也不崩
• 期望值来自独立真相源（已知正确值、规范），不是用代码同样方式算出来（那是同义反复）
• 重构只在全绿时进行，绝不红着改

与其他技能的配合

tdd 是 implement 内部的引擎，也常被 diagnosing-bugs 在修复后用来锁行为。它依赖 codebase-design 找出的深模块接缝。

相关技能：

• implement：按规格构建
• codebase-design：深模块设计
• diagnosing-bugs：纪律化调试循环
• code-review：双轴代码审查

常见问题

为什么不能先写一堆测试？

批量测试验证的是「想象中的行为」，对真实变化不敏感，还会在没理解实现前就固化测试结构。垂直切片更稳。

什么是同义反复测试？

期望值用和代码相同的方式算出来（如 expect(add(a,b)).toBe(a+b)），它恒过、永远不可能和代码冲突，等于没测。

返回章节：工程技能完全指南