关于 when-to-write-tests
when-to-write-tests 是面向代码库贡献者的测试编写指南，说明何时以及如何添加测试。它优先通过公共接口检查可观察行为，并运行变更路径，而非为每个辅助函数添加测试。
主要功能
- 01测试可观察的公共契约
- 02优先编写聚焦行为的测试
- 03运行变更路径进行冒烟检查
- 04遵循代码库的测试文件规则
适用场景
- 01判断代码变更是否需要测试
- 02覆盖已复现的公共行为缺陷
- 03避免测试私有辅助函数来验证变更
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/when-to-write-tests确认已加载。
详细介绍
何时编写测试
通过功能的接口测试可观察到的行为。遵循 codebase-design 中的通用规则和示例。 与其为每个私有辅助函数编写测试，不如优先编写少量覆盖真实行为的测试。
默认情况
不新增测试。
冒烟测试已更改的路径（运行相关内容）。这就是验证。
仅在以下情况编写测试
- 用户要求编写测试，或
- 新增或更改了可观察的公共契约，或复现了现有测试未覆盖的 bug（存储 API、HTTP 路由、迁移回填、公共计算）。
选择能通过接口测试该契约的最小测试。 对于存储，在可行时使用真实持久化路径。对于公共纯函数，直接断言其输入和输出行为。如果失败、顺序和清理属于契约的一部分，就对它们进行测试；不要为私有辅助函数或内部调用断言额外增加一层测试。
将测试放在源文件旁边，命名为 <file>.test.ts，而不是放进单独的 test/ 或 tests/ 目录。只有会启动真实服务端或 CLI，或跨越多个包的测试，才放入仓库根目录下的 tests/。
不要为以下内容编写测试
- 仅修改注释或文档
- 已由行为测试覆盖的内部辅助函数、编码器或绑定列表改写
- “每个新函数／方法”
- 顾问自行设想、但不属于契约的边界情况
- 保持相同行为的重构（现有测试已能防止回归）
遵循仓库要求
当前用户指令和仓库要求优先于本指南。添加测试前先检查现有覆盖；必需的回归测试应复现可观察到的 bug，而不是固化当前实现。 不要仅仅因为新增或移动了辅助函数就采用 TDD。成功的冒烟检查有助于验证，但不能代替必需的自动化测试。
合理示例
填充旧的入站表，应用迁移，列出事件，并断言事实和元数据均得以保留，且 matches 表已删除。
不合理示例
为每个辅助函数或注释改写各编写一个测试。断言 saveInvoice 调用了私有的 insertRow，而不是断言发票已保存。
评论
支持 Markdown