TDD 与结对编程

核心观点

TDD 与结对编程通过测试先行、角色协作和短反馈，把任务中的业务与架构知识持续转化为可验证的软件增量。

TDD 先把预期行为写成会失败的测试，再用最小实现使测试通过，最后在测试保护下改善设计。Red–Green–Refactor 的价值不只是增加测试数量，而是让需求理解、任务边界和设计判断在每个小步中接受反馈。

结对编程为这个循环提供两种互补视角：Driver 聚焦当前操作，Navigator 检查意图、设计和下一步。编写测试与编写生产代码时，两种角色可以轮换；关键不是两个人同时操作一台电脑，而是实现始终有人从更高层检查“当前改动是否仍在解决原来的任务”。

自然语言测试列表和测试代码都是知识载体。它们比一次性生成的大段实现更容易暴露对需求的误解，也能向其他成员说明当前实现覆盖了哪些行为。能写出恰当测试，意味着抽象需求已经被拆成可观察的输入、行为和结果。

架构与任务分解提供功能上下文和工作边界，测试工序进一步规定开发、验证与集成的顺序，TDD 与结对编程再在这些边界内形成可工作的产品增量。失败测试若暴露业务规则无法表达、组件职责混乱或任务粒度失控，反馈应返回业务建模或架构与任务分解重新规划，而不是在错误边界内强行实现。

但测试通过只能证明已经表达出来的行为成立，不能单独证明原始业务问题已经解决，因此还需要产品验收把增量放回业务情境观察。

在双向知识流中的位置

• 消费：任务、验收条件、架构约束和测试工序。
• 产生：测试、代码、设计判断以及可工作的软件增量。
• 校验：用测试执行、Navigator 检查和 Red–Green–Refactor 的短反馈暴露偏差。
• 回流：根据失败性质修正实现、任务、架构、测试策略或业务规则。

知识连接

• 属于：实现知识反馈循环——Red–Green–Refactor、结对与评审提供最短半径的实现反馈。
• 建立在：架构与任务分解——明确的功能上下文使测试和实现能够保持可控粒度。
• 建立在：测试工序的核心思想和实践要点——测试工序规定功能上下文的开发、验证与集成顺序。
• 反馈到：业务建模或架构与任务分解——失败测试可能暴露业务规则、组件边界或任务粒度的理解错误。
• 例证：TDD 证明开发者理解了需求——测试把需求理解变成其他人可以运行和检查的表达。
• 导向：功能方案反馈循环——多个可验证增量汇聚后，由 Desk Check 判断功能方案是否仍然成立。

⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠ You can decompress Drawing data with the command palette: ‘Decompress current Excalidraw file’. For more info check in plugin settings under ‘Saving’

Excalidraw Data

Text Elements

选择一个预期行为

结对完成最小实现

测试与 Navigator 验证

Red → Green → Refactor

选择下一行为，开始新一轮

Embedded Files

5baf58656ed1d13988d78558ecc32f4041152a72: Icon - 结对编程, 驾驶员, 导航员, 协作, pair programming - Own.excalidraw

05f4e3b649b167cb280463c52fc6a3be18ef3b52: Icon - 测试, 聚光灯, 验证, 检查, test spotlight - Own.excalidraw

e035291a41ac49e40af95c090d579318947253a5: Icon - 任务清单, 待办, 分解, 步骤, task list - Own.excalidraw