verify-test-cases

验证自从从基准分支分出以来所有已修改测试文件中测试用例的质量和正确性。

用法：

• /verify-test-cases - 验证自从从基准分支分出以来已修改的测试文件

说明：

1. 确定基准分支：

   • 检查当前目录中是否存在 .agent 文件
   • 如果存在，读取该文件并查找 baseBranch=<value> 行，以提取基准分支
   • 如果没有 .agent 文件或没有 baseBranch 键，则默认使用 main

2. 识别分支以来已修改的测试文件：

   • 运行 git diff --name-only <base-branch>...HEAD，获取自从从基准分支分出以来所有已修改的文件
   • 使用常见模式筛选测试文件：
     • *.test.*、*.spec.*（JS/TS）
     • test_*.py、*_test.py（Python）
     • *_test.go（Go）
     • *_test.rs、tests/ 目录下的文件（Rust）
     • __tests__/、test/、tests/、spec/ 目录下的文件
   • 如果没有测试文件被修改，则告知用户并停止

3. 使用团队分析测试文件：

   启动并行 Agent，并发分析测试文件。每个 Agent 独立审查一个或多个测试文件。

   a) 根据测试文件数量确定团队规模：

   • 1–2 个测试文件 → 直接分析（无需团队）
   • 3–5 个测试文件 → 启动 2 个审查 Agent
   • 6 个或更多测试文件 → 启动 3 个审查 Agent

   b) 如果启动团队：

   • 使用 TeamCreate，团队名称为 verify-tests
   • 使用 TaskCreate 为每位审查者创建一个任务：“Review test files: <file1>, <file2>, ...”
   • 将测试文件分配给各位审查者；尽可能将测试同一源模块的文件分在一起
   • 使用 Task 工具启动审查者（subagent_type: general-purpose），并设置 run_in_background: true 和团队名称
   • 每位审查者需要收到：
     • 要分析的测试文件列表
     • 同时读取被测源文件以了解上下文的说明
     • 完整的验证清单（以下第 4 和第 5 步）
   • 审查者必须将其任务标记为已完成，并向团队负责人发送调查结果
   • 等待所有审查者完成，然后汇总结果

   c) 如果直接分析（1–2 个文件）：

   • 按照第 4 和第 5 步自行读取并分析测试文件

4. 验证测试用例是否合理： 对每个测试文件，检查以下内容：

   a. 测试描述是否符合行为：

   • 测试名称或描述准确反映测试内容
   • 测试主体确实测试了名称所述内容

   b. 断言是否有意义：

   • 测试包含实际断言（而非仅运行代码却不检查结果）
   • 断言验证了正确的内容（而非对所有内容都只使用 toBeTruthy()）
   • 适当覆盖边界情况和临界条件

   c. 测试设置是否正确：

   • 模拟对象和存根适用于所测内容
   • 测试夹具和数据符合实际情况
   • 设置和清理操作能正确初始化和清理状态

   d. 测试是否相互独立：

   • 测试不依赖执行顺序
   • 共享状态不会在测试间泄漏

   e. 测试是否与源代码匹配：

   • 测试覆盖实际的函数签名和行为
   • 测试没有针对过时或不存在的 API

5. 检查重复内容： 对每个测试文件以及所有已修改的测试文件之间进行检查：

   a. 完全重复：

   • 测试主体相同或几乎相同
   • 未经修改的复制粘贴测试

   b. 逻辑重复：

   • 不同测试验证完全相同的行为
   • 覆盖内容有大量重叠的测试

   c. 冗余断言：

   • 不同测试中的多个断言检查同一内容
   • 被其他测试完全包含的测试

6. 报告调查结果：

   如果使用了团队，则汇总所有审查者的调查结果，并清理团队（向每位审查者发送 shutdown_request，然后执行 TeamDelete）。 按以下格式输出：

## Test Verification Report

### Files Analyzed
- `path/to/file.test.ts` (N tests)
- `path/to/other.spec.js` (N tests)

### Issues Found

#### Nonsensical / Incorrect Tests
- **file.test.ts:42** `"should handle empty input"` - Test passes a non-empty string, contradicting its description
- **file.test.ts:67** `"should return user"` - No assertion on the return value

#### Duplicate Tests
- **file.test.ts:30** and **file.test.ts:55** - Both test the same "valid email" scenario with identical logic
- **other.spec.js:12** and **other.spec.js:40** - Logically equivalent: both verify default config values

#### Missing Coverage
- `createUser()` has no test for the error/rejection path
- Edge case: empty array input is not tested for `processItems()`

### Summary
- Total test files analyzed: N
- Total test cases reviewed: N
- Issues found: N
- Duplicates found: N
- Verdict: PASS / NEEDS ATTENTION

7. 覆盖率门禁（测试用例变更定稿后必须执行）：

   • 等待用户明确确认测试用例工作已完成：用户批准你提出的修改（你应用修改后）、确认已自行应用修改，或确认报告无需修改测试并准备继续。
   • 选择覆盖率命令（在仓库根目录执行）。如果没有 package.json，告知用户无法为此工作区运行覆盖率，然后在报告后停止。
   • **Node.js 项目：**读取 package.json 中的 scripts 和依赖项（dependencies / devDependencies / peerDependencies）：
     1. 如果存在 test:coverage 脚本，使用 npm run test:coverage。
     2. 否则，如果项目使用 Vitest（例如依赖项中有 vitest，或 test 脚本调用 vitest），运行 npx vitest run --coverage。
     3. 否则，如果项目使用 Jest（例如依赖项中有 jest，或 test 脚本调用 jest），运行 npx jest --coverage。
     4. 否则，如果有其他明确运行测试并生成覆盖率的脚本（例如 coverage、test -- --coverage），通过 npm run <script> 运行该脚本。
     5. 如果以上条件均不满足，告知用户无法确定覆盖率命令，然后在报告后停止。
   • 运行所选命令。如果运行失败（退出码非零、测试失败，或未达到项目配置的覆盖率阈值），修复测试（仅当生产代码正确而测试有误时，才调整测试）。重新运行相同命令。重复此过程，直到命令成功退出。
   • 此步骤成功前，不要将验证报告视为完整。

8. 处理边缘情况：

   • 如果当前分支相对于基分支没有提交，告知用户并停止
   • 如果修改的文件同时包含测试文件和源文件，使用源文件作为上下文，但仅报告测试文件
   • 如果测试文件导入了你找不到的文件，注明此情况，但继续分析
   • 对于非常大的测试文件（超过 500 行），使用针对这些文件的 git diff，重点分析已更改的部分