test-driven-development

测试驱动开发

通过公共接口编写少量行为测试。仅当用户要求采用 TDD／测试优先，或仓库说明要求执行这一周期时，才选择使用此技能。遵循 codebase-design 中的通用可读性规则，以及 when-to-write-tests 中的测试范围说明。

适用场景

• 用户要求采用 TDD、测试优先或红-绿-重构
• 仓库说明要求此次变更先编写失败测试

不适用场景

• 用户未要求、仓库也未要求采用 TDD 的常规实现或重构
• 仅移动私有辅助函数、修改注释或编辑文档
• 用户要求契约测试，但未要求或未规定采用 TDD；使用 when-to-write-tests 来选择测试
• “每个新函数／方法”
• 顾问凭空设想、并非契约内容的边界情况
• 现有测试已经覆盖公共行为

默认不新增测试。对变更路径进行冒烟测试。参见 when-to-write-tests。

编写内容

编写一个或少量测试，走真实路径：从公共边界输入 → 经过系统 → 得到可观察的结果。

好的做法：填充旧的入站表，应用迁移，列出事件，并断言事实和元数据均得以保留。

不好的做法：为每个辅助函数、编码器或绑定列表重写分别编写测试。

优先使用真实协作者，而非模拟对象。针对这些契约测试路由／存储／UI 路径；通过输入和输出来测试公共纯函数。辅助说明：tests.md、mocking.md。

测试放置位置

放在源文件旁边：foo.test.ts 与 foo.ts 同目录。不要在包中另建顶层 test/ 或 tests/ 目录来存放这些测试。

例外：启动真实服务端或 CLI，或跨越多个包的端到端测试，放在仓库根目录下的 tests/ 中（例如 tests/smoke.test.ts）。

测试周期（仅在适用此技能时）

1. 用一句话描述一个可观察的行为。
2. 通过其公共接口编写一个会失败的测试。
3. 编写能使测试通过的最简单完整实现。
4. 仅在有助于理解时重构；将相关逻辑放在一起。
5. 对下一个必需行为重复上述步骤。不要为每个新辅助函数添加测试。

当契约要求时，纳入失败、完成和清理行为； 公共纯函数不需要覆盖整个应用的端到端测试框架。

不要为了重新开始 TDD 而删除可正常工作的代码。在用户未要求、仓库也未要求采用 TDD 周期时，遵循仓库按比例验证的策略。

冲突

用户说明和仓库要求优先。使用 when-to-write-tests 避免重复测试，而不是借此免除必需的公共行为或生命周期覆盖。