tdd

测试驱动开发

核心规则

按垂直的红—绿—重构切片推进：

1. RED：针对一种可观察行为编写一个测试。
2. GREEN：只做最小的生产代码改动，让该测试通过。
3. REFACTOR：仅在测试保持通过时进行清理。

不要在实现前批量编写设想中的测试。每个新测试都应针对上一轮让你了解的实际行为和接口。

Plaited 默认设置

• 使用 bun test 运行定向测试，使用 bun --bun tsc --noEmit 进行类型检查。
• 使用 test，而不是 it，并用 describe 组织测试。
• 优先使用真实依赖和真实运行时边界，而不是模拟对象。
• 仅模拟外部边界，例如远程 API、时间、随机性或罕见的文件系统情况。
• 避免有条件的断言：先断言分支，再断言分支特有的值。
• 对条件分支、回退逻辑和错误路径都进行测试。
• 测试公共接口和运行时契约，而不是私有辅助函数。
• 针对所修改的区域，遵循适用的仓库技能和 AGENTS.md 规则。

开始工作时

先探索代码库。如果可以从代码、测试或文档中找到公共接口、预期行为或风险边界，就依据这些证据，而不是询问用户。

只有在无法找到相关决策，且贸然假设存在风险时，才提出一个简短的问题，并附上你建议的答案。

编写生产代码前，先确定：

• 要测试的公共接口或运行时边界
• 首个要验证的可观察行为
• 本轮要运行的定向测试命令
• 交付前所需的更广泛验证

循环规范

针对每种行为：

1. 添加或更新且仅更新一个聚焦的测试。
2. 运行定向测试，确认它因预期原因失败。
3. 仅实现通过该测试所需的代码。
4. 运行同一个定向测试，确认它通过。
5. 如有必要，进行重构，然后重新运行受影响的测试。

如果生产代码尚未更改，测试就已经通过，那么它就不能作为有效的 RED 信号。应收紧测试、选择另一种行为，或说明现有覆盖为何已能证明该行为。

参考文件

• references/tests.md：行为测试示例及实现细节方面的警示
• references/mocking.md：仅针对边界进行模拟的指南
• references/interface-design.md：可测试的公共接口设计
• references/deep-modules.md：小接口、深实现的指南
• references/refactoring.md：通过绿灯后要运行的重构检查