Skip to content
台灯与工作台

编写测试

写测试的要点：先定风格、把完成标准落到可运行的测试上、收尾审查覆盖盲区。这套流程固定且每次写测试都要走，值得打包成一个 skill——构建一次，以后写测试一句话触发。

构建 write-tests skill

Section titled “构建 write-tests skill”
帮我构建一个编写测试的 skill，命名 write-tests，
保存到 ~/.claude/skills/write-tests/。


流程要求：
1. 写测试前先看项目已有测试，遵循其命名、断言风格和组织方式
2. 已有测试失败时直接修复：跑测试看报错 → 定位断点对应代码 → 修改 → 再跑
3. 用 /goal 声明可验证的完成标准（如"相关测试全部通过、无新 warning"）
4. 完成后派 verification 子代理审查覆盖：异常路径、断言精确性、边界情况

生成的 SKILL.md 内容类似这样：

---
name: write-tests
description: 编写测试时使用。用户要求写测试、补覆盖、修复失败用例时触发。
---


# 编写测试


1. **先看风格**：参考项目已有测试的命名、断言方式和组织习惯，不自己发明标准
2. **修复失败用例**：跑测试看报错 → 定位断点对应的代码 → 修改实现或测试 →
   再跑，直到通过
3. **声明完成标准**：用 /goal 把验收条件写成可验证目标
   （如"相关测试全部通过、无新 warning"），每轮对照检查，完成后验证
4. **覆盖审查**：派 verification 子代理审查：是否覆盖异常路径（不只是 happy path）、
   断言是否精确（关键字段没漏）、边界情况（空输入、超长输入、并发冲突）

流程在做什么

Section titled “流程在做什么”
  • 参考已有风格：项目测试的写法就是标准。让 Peri 照现有用例执行，比描述抽象要求可靠
  • 完成标准落到测试：目标是否达成由测试结果判定，而不是对话里的口头确认
  • 审查覆盖：自己写的测试有盲区——只测 happy path、断言漏关键字段，独立视角能看出来

使用

Section titled “使用”
用 write-tests 给 src/utils/format.rs 写测试，参考 src/utils/__tests__/ 中已有用例的风格

Peri 会按流程走：先看风格 → 写测试 → /goal 声明完成标准 → 派 verification 审查覆盖。skill 的存放位置、自动加载机制和修改方式，见探索陌生代码库的说明。

进阶：TDD 流程

Section titled “进阶：TDD 流程”

想从测试出发构建新功能（而不是功能写完再补测试），用 tdd skill 走红-绿-重构：先写失败的测试 → 写通过测试的最小实现 → 重构。superpowers 的 test-driven-development 提供同款流程。

获取方式：

Terminal window
npx skills add https://github.com/konghayao/peri --skill tdd

用法示例：

/tdd 实现用户邀请功能的核心逻辑

skill 会先写失败测试，再写最小实现让测试通过，最后重构。完整的流程对比见 mattpocock/skills。

下一步

Section titled “下一步”