用途
这个技能面向的场景是：用户希望防止回归、提升测试覆盖率，或提出“add tests”“improve coverage”“we keep breaking this”“write regression tests”等需求。它的核心目标是编写专门用于防止回归的测试——回归即那些已经修复但可能再次出现的 bug。
主要能力与流程
1. 识别回归风险
资料列出回归的高风险区域：
- 最近被修复的代码（修复可能不完整）
- 频繁被修改的代码（高改动率=高风险）
- 带有复杂条件逻辑的代码（分支多=出错方式多）
- 处于集成边界的代码（两个系统相接处）
- 没有任何现有测试的代码
2. 编写特征测试（Characterization Tests）
在修改任何代码之前，先捕获当前行为。资料给出的示例是一条用于记录当前行为的特征测试：当没有条目匹配过滤器时应返回空数组。如果该测试在重构期间失败，说明行为被改变了（无论是否有意）。
3. 为已修复的 bug 编写回归测试
每一次 bug 修复都需要一条回归测试。资料示例中引用了 issue 链接，说明该 bug 是输入包含 unicode emoji 时处理失败，并测试应能处理输入中的 unicode emoji。
资料给出的回归测试规则：
- 在注释中引用原始 issue/bug
- 测试触发该 bug 的确切场景
- 测试相近变体（如果 emoji 会破坏它，也要测试其他 unicode）
- 放在相关测试附近，而不是单独的“regression”文件里
4. 覆盖率指导的测试编写
用于发现未被测试的代码路径。资料给出的命令是 pnpm test --coverage 生成覆盖率报告，并寻找：未被覆盖的分支（从未命中的 if/else 路径）、未被覆盖的函数（死代码还是缺少测试？）、低覆盖率文件（行覆盖率低于 60%）。
优先覆盖：公共 API 函数（用户依赖这些）、错误处理路径（失败应当是可预测的）、业务逻辑中的边界情况、数据校验与转换。
5. 变异测试（进阶）
如果覆盖率很高但 bug 仍然漏过，说明测试可能比较弱。资料给出的检查方式：把 > 改成 >=，是否有测试失败？移除一个空值检查，是否有测试失败？更改一个常量，是否有测试失败？如果没有测试失败，说明测试检查的东西不对。
测试组织
资料给出的目录结构为：src/ 下包含 module.ts 与 __tests__/，后者包含 module.test.ts（单元测试）和 module.integration.ts（集成测试）。
组织建议：
- 按行为而非按方法对测试分组
- 使用 describe 块组织相关场景
- 测试名称应是句子，例如“should reject invalid email format”
- 每个概念一个断言（但针对一个逻辑断言使用多个 expect 调用是可以的）
适用场景与限制
该技能适用于需要防止回归、补强测试覆盖、或反复被同一类问题破坏的代码库。
资料未提供关于收费、价格、支持的平台或具体运行环境的说明，这些信息暂未提供。