用途
unit-tests 是一个测试质量审计器（test quality auditor），用于审查现有测试套件并使其变好，而不是变大。它的核心判断是：更多测试不等于更高质量。一个臃肿但放行 bug 的测试套件，比一个精简却能捕获真实回归的套件更糟。
默认姿态是怀疑：每一个现有测试都必须证明自己存在的理由。它构建的是「检查（checks）」而非「测试（testing）」——自动化断言只能确认既有信念，真正的测试需要人类判断。它不会评估「可用性」「品味」或 UI 流程是否「直观」这类需要人类判断的内容。
主要能力
- 默认审计并报告：只当用户明确要求改动时才修改测试。
- 发现测试：用 Glob 模式查找测试文件（
**/*.test.*、**/*.spec.*、**/__tests__/**、**/tests/**、**/*Test.php），识别测试框架（Jest、PHPUnit 等）并找到运行方式，读取测试配置。 - 建立基线：运行现有套件记录通过/失败/跳过数量与运行时长，作为「改动前」基准。
- 逐文件审计：同时阅读测试文件与其被测源文件，应用决策框架和异味目录，产出审计报告。
- 按需修改：删除不满足决策框架的测试（逐条说明理由）、重写可修复异味的测试、仅在存在真实覆盖缺口时新增测试，然后重新运行验证。
- 结构化报告：输出删除、重写、保留、新增、mock 依赖、运行时长影响、不稳定测试、静默通过风险等分节。
决策框架（对每个测试按顺序自问）
- 能否用一句话概括该测试意图（「本测试防止 [某具体回归]」）？不能则是覆盖率凑数，考虑删除。
- 它防止什么回归？说不出具体场景则无目的。
- 它是否是给出信心的最廉价测试？优先单元 > 集成 > E2E。以边界而非运行器来分类测试。
- 它验证的是我们的代码还是框架的代码？不要测试 React 能渲染、Express 能路由。
- 它是否确定性？不稳定测试比没有测试更糟。
- 它是否与其他测试重复？
常见异味目录（部分）
恒真测试、框架测试器、实现间谍、复制粘贴测试、过度 mock、永不失败的测试、不稳定测试、僵尸测试、覆盖率凑数、无断言测试、回避者、只测 happy path、回声测试、mock 测 mock、CSS 类耦合、构造函数漂移、AI 文档块臃肿、慢测试、昂贵装置中的慢矩阵、可变共享 fixture、单元套件中的实时外部依赖。每种异味都对应删除、重写或拆分等动作。
关键规则
必须：为每次删除给出一行理由；改动前后都运行套件；保持套件快速；保留回归覆盖；以行为命名测试（如 returns_empty_array_when_no_items_match_filter）。
禁止：为让测试通过而修改断言（绝不改变 oracle——期望 10.0 得到 10.5 是回归信号，应标记给人工审查）；为增加数量或覆盖率而加测试；为琐碎代码加测试；到处 mock；写重复覆盖的测试；忽视运行时长。
适用场景
被要求审查测试、改进测试质量、清理测试套件时；审查由 AI 辅助编写的测试 PR 时（需额外核查构造函数签名、断言是否验证正确内容、回声测试、未测试的高风险代码如加密/认证/HTTP 客户端）；测试套件臃肿、包含大量无效或耦合测试时。
平台与框架指导
- JavaScript/Jest：React 组件测行为而非内部，优先
getByRole > getByText > getByLabelText > getByTestId，不用 CSS 选择器；快照较弱，少用；异步测试需确定性完成，不用任意 setTimeout。 - WordPress/PHP：仅在需要 WordPress API 时用
WP_UnitTestCase，纯 PHP 逻辑用普通PHPUnit\Framework\TestCase；不要测 add_action 是否工作，而测回调行为；不测 WordPress 自身 REST 基础设施；不用真实 sleep()/usleep() 制造时间差，应显式设置时间戳或注入时钟。
限制
具体收费、价格、平台支持等信息暂未提供。该技能依赖具体项目的测试框架与配置；无法替代人工探索式测试。