tdd

测试驱动开发

在每个红 → 绿循环中应用以下测试质量规则。

阅读 GLOSSARY.md，然后使用 docs/decisions/README.md，仅加载与被测行为相关的决策主题。如果代码、规范和决策契约在决策层面发生冲突，请明确指出冲突，而不是默默自行选择。测试名称和公共接口中应使用当前术语。

优质测试

通过公共接口测试行为，避免内部重构导致测试失效。使用说明能力测试内容的规范式名称。

仅在外部 API、时间和随机性等系统边界处使用模拟；优先使用真实测试数据库，而非模拟数据库。

接缝

接缝是测试观察行为而无需深入内部实现的公共边界。

创建新接缝前，先复用已有接缝。仅为稳定的用例或领域概念创建接缝，不要为名称可能变化的实现辅助项创建接缝。

根据已达成共识的行为和现有公共接口选择测试接缝，优先覆盖关键路径和复杂逻辑。简要说明所选接缝及其要验证的行为，然后开始编写第一个测试。

通过仓库证据解决技术上的不确定性。只有在预期行为仍不明确，或继续操作会改变已达成共识的产品契约时，才询问用户。

反模式

• 与实现耦合：模拟内部协作者、测试私有方法，或通过旁路验证。这类测试会在实现改变而行为不变时失效。
• 同义反复：使用与代码相同的逻辑推导预期值，导致断言必然通过。应使用已知字面值、演算示例或规范等独立来源。
• 横向切片：在开始实现前编写大量测试。先实现一个失败测试及使其通过所需的最少代码，再选择下一个测试。

循环规则

• 先红后绿。 先编写失败测试，再编写刚好足以使其通过的代码。不要预判未来的测试，也不要添加臆测功能。
• 一次一个切片。 每个循环使用一个接缝、一个测试和一个最小实现。
• 绿后重构。 重构期间保持测试通过。本循环不单独发起评审：完成后的差异应由负责该工作的工作流进行评审，或由用户发起评审。