tdd

TDD

在事先约定的接缝处，以小步进行红-绿循环。在启动运行中，接缝列表是 C2 批准的输出；启动之外，必须在第一个测试编写之前与用户约定接缝——未经任何人批准的接缝，不得编写测试。

循环

一个测试 → 一个实现 → 重复：

1. 在下一个接缝处编写测试。运行测试。确认它因预期的原因失败——无法失败的测试就不是测试。
2. 实现最小改动，使测试通过。
3. 重复。每个测试都是一颗示踪弹：沿着行为路径走得窄而完整，而不是孤立地完成某一层。

规则

• 预期值必须来自独立的事实来源——规范中的一行内容、经过演算的示例或有文档记录的输出。绝不能来自被测实现：断言代码碰巧做了什么的测试，只是镜子，不是检查。
• 只在接缝声明的边界类别处进行替换——进程内、可在本地替换、自有远程端口或真正的外部依赖；C2 会为每个接缝记录其类别。不得在测试所覆盖的边界内部进行替换。
• 重构不属于这个循环。它属于审查阶段，由修复工作者负责。不要在红-绿循环中途重构。
• 修复 Bug 时，先编写能够复现它的失败测试——先复现再推理论，这是调试者的准则。
• 提出接缝时，用一行说明它能捕获什么、会放过什么——无法估量代价的接缝选择只是猜测，不是决策。

不适用任何接缝时

如果无法在任何已批准的接缝处测试该行为，就停止并说明情况：将缺失的接缝报告为一项发现（它会进入 architecture-survey 和 refit），而不是自行编造接缝或通过内部实现进行测试。

输出

• 使用的接缝列表，包括边界类别以及每个接缝的捕获/遗漏说明
• 红/绿证据——失败运行和通过运行
• 任何接缝缺失发现