tdd

测试驱动开发

每次通过一个行为测试来驱动实现。如果需要判断测试是否必要或质量如何，但不采用测试先行工作流，请改为阅读 test-judgment.md。

前置条件

使用请求或已接受计划中的公共接口和目标行为。只有缺少的决策会妨碍编写有意义的测试时才提问；不要再次确认已经确定的选择。

每次编写新测试前，使用 test-necessity gate 说明该测试能捕获的回归，并检查是否有重复覆盖。如果该门槛否决了某项测试，就完成相应切片，不要为了制造 RED 而硬写测试，并报告豁免原因。仅凭文件类别永远不能获得豁免。

红—绿—重构

1. 为一种可观察行为编写一个聚焦的测试。从外向内开始：第一个测试应处于观察该行为的层级——如果环境能够触达，就编写集成测试、CLI 测试或端到端测试；只有在实现需要时，才继续编写范围更窄的测试。运行测试，并确认它因预期原因而 RED，而不是因无关的编译或设置失败。
2. 编写能使测试变为 GREEN 的最小生产代码改动，然后运行测试。
3. 在 GREEN 状态下重构，并重新运行受影响的测试。对下一个行为重复上述步骤，直到覆盖已接受的目标。

如果测试由单独的测试作者编写，实现者应将这些测试视为既定内容：不得编辑或弱化测试；如果认为某项测试有误，应说明理由并将其交还给作者或用户。

不要先写完所有测试，再编写所有实现。纵向切片能让每个测试都基于前一个周期揭示的事实，而非臆想的实现。

阅读和基线检查可以在 RED 之前进行。会改变行为的生产代码编辑则不可以。除非出现新的范围、设计或安全决策，否则不要在周期之间暂停并等待用户批准。

只阅读当前切片所需内容

• tests.md：测试质量存疑时参考的具体示例。
• mocking.md：如何选择需要隔离的边界。
• refactoring.md：如何重构通过测试的实现。
• verification-placement.md：判断类型检查器、生成器、兼容性检查还是测试负责处理某项关注点。

完成标准

每个目标行为都必须有通过公共接口进行的测试；每项测试都必须在对应生产代码实现之前，因预期原因而 RED；受影响的测试必须为 GREEN。报告受阻的验证或仍未覆盖的行为，不要声称已完成。豁免的切片应根据 test judgment，记录负责该关注点的机制，或明确说明不存在这样的机制。