mattpocock 的 TDD 和 code-review 有什么区别？测试后怎样审查

mattpocock 的 TDD 和 code-review 有什么区别？测试后怎样审查

mattpocock 的 tdd 用明确行为推动实现；code-review 对照固定代码基准，分别检查项目规范和原始需求。测试通过以后仍值得审查，因为测试可能遗漏需求，代码也可能偏离仓库约定。当前 code-review 的职责有清楚边界，不能把它当成会自动查出所有竞态和运行错误的通用扫描器。作者 code-review 说明

把两者用在同一项工作中，可以先完成可验证的行为，再对稳定的差异集中审查。下面用“导出订单时处理退款金额”举例，避免把测试和审查都写成同一份检查表。

TDD 先约束一个确定的行为

假设需求已经明确：导出 CSV 要分别展示付款金额、退款金额和净额；付款 1000 元、退款 200 元时，净额为 800 元。先用这个小样本建立失败测试，再实现到通过。下一步才处理没有退款、部分字段缺失等情况。

当前 tdd 文档采用 red-green 小步循环，要求有可独立判断的预期，并依赖 codebase-design 提供接口设计用语。它已将重构从循环阶段中移出，具体重构安排交给审查与后续实现处理。作者 TDD 说明

执行前先和需求负责人确认要约束哪些行为、在哪一层观察结果，再开始写测试。tdd 提供方法参考，完整循环由开发者或 implement 等执行技能推进，单独加载这份文件不表示已经运行测试。

测试适合观察公开结果，比如导出内容中的金额是否正确。若只断言内部函数被调用一次，金额算错时测试也可能通过。先写清“用户应该收到什么”，再决定在哪里观察它，能够减少测试跟着实现一起出错的情况。

审查分开看需求与规范

同一份修改可以在金额测试上全部通过，却只导出当前页，而需求要求导出全部筛选结果。这是需求没有实现完整。另一种情况是行为正确，但新代码绕过项目现有导出模块，另起一套金额格式化逻辑，增加了后续维护负担。

两个审查方向应该分别给结论。规范没问题，不能抵消漏做功能；需求完成了，也不能自动证明实现方式符合仓库约定。

给 code-review 一份明确的比较范围

当前技能比较的是 <固定基准>...HEAD，不包含暂存区和工作区里尚未提交的修改。先把本次候选整理成可审查的本地提交，并记录 HEAD；如果暂时不能提交，就另行安排明确覆盖未提交差异的审查，不能把这个 skill 的结果当成本次验收。提交只纳入自己负责的文件，不能为审查把别人的改动一起提交。

固定基准可以是实际存在的提交、分支或标签。不要只说“看看最近改的代码”，让它猜最近指的是哪里。需求也给出路径或已有问题单，避免审查模型临时编造验收标准。

使用 mattpocock 的 code-review 审查本次订单导出修改。
比较基准：填写本项目已经确认的提交或分支。
候选 HEAD：填写包含本次修改的已确认提交。
需求依据：填写本次需求文档路径。
分别报告 Standards 和 Spec 发现，指出对应依据与代码位置。
本轮只审查；先汇总问题，不直接修改其他人的工作。

运行前查看当前分支、未提交变更和比较范围。如果用户与另一个任务正在修改同一模块，先圈定本次候选；否则审查报告可能把尚未完成的并行工作也当成本次结果。

怀疑运行缺陷时，安排对应检查

“偶尔重复导出”“请求失败后卡住”需要可运行的复现。可以先用 diagnosing-bugs 缩小触发条件，再根据根因补行为测试。不能因为 Spec 和 Standards 都通过，就跳过这类已观察到的问题。

浏览器里同样要走一遍实际路径：选择筛选条件、导出、打开文件、改变条件再导出，检查文件内容是否对应当前页面。后端测试通过，并不自动覆盖下载动作、文件名或浏览器缓存行为。

修复集中处理，再核对最终版本

把审查发现按影响整理，先修影响验收的需求遗漏和规则冲突。调整以后，重跑受影响的测试和操作路径，确保检查的是最终代码。已经通过且没有被新改动影响的检查，无需为了次数不断重复。

交付记录可以很短：采用哪个基准、实现了哪些行为、审查发现怎样解决、哪些运行条件仍未覆盖。下次接手的人能据此继续，而不是只看见一句“测试全绿”。

技能选择可以回到 mattpocock skills 场景指南，具体缺陷处理可参考 Codex 修复现有分页 Bug。作者的 日常 Skills 视频原页也展示了如何把需求讨论和测试放进日常开发。

如果日常已经用 Codex 连续实现和审查项目，可按用量查看 ChatGPT 订阅服务及开票说明。