claude-howto 中的 test-checker 子代理PR 测试覆盖与质量分析的自动化检查方案【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto本文以 claude-howto 仓库中 pr-review 插件的test-checker子代理定义ja/07-plugins/pr-review/agents/test-checker.md为核心完整解析这个 Claude Code 插件子代理的 frontmatter 定义、四项分析职责以及它如何与/check-tests、/review-pr命令、pre-review Hook 和 GitHub MCP 服务器组合成一条完整的 PR 测试审查流水线。读完后你能掌握如何为 Claude Code 编写一个只读型的代码审查子代理以及它在插件工作流中的真实调用链与运行前提。一、test-checker 的完整定义test-checker 是 pr-review 插件内置的三个子代理之一定位是测试覆盖与质量分析。其完整定义文件为 test-checker.md日文版位于 ja/07-plugins/pr-review/agents/test-checker.md结构非常典型--- name: test-checker description: Test coverage and quality analysis tools: Read, Bash, Grep --- # Test Checker Analyzes test coverage and quality: - Coverage percentage - Missing test cases - Test quality assessment - Edge case identification逐字段解读字段取值含义nametest-checker子代理唯一标识供命令/主代理委派时引用descriptionTest coverage and quality analysis一句话职责描述用于 Claude 判断何时该把它拉进上下文toolsRead, Bash, Grep工具白名单只能读文件、跑命令、做文本检索没有 Write 权限是典型的只读审查者定义文件列出了它的四项核心分析职责这也是理解后续所有调用链的骨架Coverage percentage覆盖率——运行测试统计工具得到整体/变更文件的覆盖比例Missing test cases缺失用例——对照被测代码路径指出哪些分支还没有测试Test quality assessment质量评估——判断现有测试是否有效例如只断言不抛错的弱测试Edge case identification边界场景识别——识别空值、边界条件、错误输入等应当覆盖而未覆盖的场景。文档元信息标注其面向 Claude Code 2.1.220Last Updated: August 4, 2026声明的兼容模型包括 Claude Fable 5、Opus 5、Sonnet 5、Sonnet 4.6、Opus 4.8、Haiku 4.5。二、它所处的位置pr-review 插件全景test-checker 不是孤立存在的。pr-review 插件 README 说明它是一个完整的 PR 审查工作流包把多种 Claude Code 扩展机制捆绑在一起Slash 命令/review-pr综合审查、/check-security安全审查、/check-tests测试覆盖分析子代理security-reviewer、test-checker、performance-analyzer三个专家角色MCP 服务器GitHub 集成用于拉取 PR 数据Hookpre-review.js审查前置校验。安装方式是一条命令/plugin install pr-review在这套组合里test-checker 扮演测试专家角色由命令侧的两个入口触发独立入口/check-tests以及综合入口/review-pr的委派步骤。三、独立入口/check-tests 的五步分析流程与 test-checker 直接对应的命令定义在 check-tests.md它把子代理的四项职责落成可执行的五步流程name: Test Coverage Check description: Verify test coverage and quality1. Check test coverage percentage # 检查测试覆盖率 2. Identify untested code paths # 定位未测试的代码路径 3. Review test quality # 评审测试质量 4. Suggest missing test cases # 建议缺失的测试用例 5. Verify edge cases are covered # 验证边界场景是否被覆盖可以看到命令侧的五步是子代理四项职责的展开版第 1 步对应 coverage percentage第 2、4 步细化了 missing test cases第 3 步对应 test quality assessment第 5 步对应 edge case identification。由于 test-checker 的tools白名单包含Bash它可以真正执行项目自带的测试与覆盖率命令例如带 coverage 报告的单测运行器而GrepRead则用于对照源码与测试文件找出有代码路径但无断言的缺口。四、综合入口/review-pr 的委派链与前置 Hook4.1 审查编排/review-pr 是插件的主命令声明它启动一项包含五个环节的完整 PR 审查安全分析、测试覆盖验证、文档更新检查、代码质量检查、性能影响评估。按 pr-review README 给出的示例工作流一次/review-pr的执行链路为运行 pre-review hook校验 git 仓库通过 GitHub MCP 拉取 PR 数据委派security-reviewer子代理做安全审查委派test-checker子代理做测试分析委派performance-analyzer子代理做性能评估汇总所有发现synthesizes all findings输出综合审查报告。README 中的示例报告输出展示了各子代理结果如何被聚合Result: ✅ Security: No critical issues found ⚠️ Testing: Coverage is 65%, recommend 80% ✅ Performance: No significant impact Recommendations: Add tests for edge cases其中Coverage is 65%, recommend 80%正是 test-checker 覆盖分析职责的产物——注意它与 test-engineer 子代理 中声明的Minimum 80% code coverage标准一致说明80% 覆盖率是仓库内测试类代理共享的验收基线。4.2 pre-review hook 的源码细节工作流第 1 步的 pre-review.js 值得细看它决定了审查能否开始// Check if git repository const { execSync } require(child_process); try { execSync(git rev-parse --git-dir, { stdio: pipe }); } catch (error) { console.error(❌ Not a git repository); process.exit(1); } // Check for uncommitted changes try { const status execSync(git status --porcelain, { encoding: utf-8 }); if (status.trim()) { console.warn(⚠️ Warning: Uncommitted changes detected); } } catch (error) { console.error(❌ Failed to check git status); process.exit(1); }从源码结构看它做两件事用git rev-parse --git-dir确认当前目录是 git 仓库否则直接exit(1)阻断审查以及用git status --porcelain检查未提交改动——有未提交内容时只告警不阻断因为 test-checker 分析的是工作区现状。这个硬校验 软告警的分级设计保证覆盖率统计有确定的代码基线。4.3 PR 数据从哪来GitHub MCP工作流第 2 步依赖 github-config.json 中声明的 MCP 服务器{ mcpServers: { github: { command: npx, args: [modelcontextprotocol/server-github], env: { GITHUB_TOKEN: ${GITHUB_TOKEN} } } } }它通过npx启动modelcontextprotocol/server-github并注入GITHUB_TOKEN环境变量。这意味着 test-checker 分析哪些变更需要补测试时可以基于 MCP 提供的 PR diff/文件变更范围来缩小检查面而不是全仓扫描。五、设计要点为什么 test-checker 是只读的把 test-checker 与仓库中另一个测试向代理对比能看清它的角色边界维度test-checker插件子代理test-engineer独立子代理toolsRead, Bash, GrepRead, Write, Bash, Grep是否可写文件否是可创建测试文件定位审查现有测试覆盖率、缺漏、质量、边界编写新测试并运行验证触发方式由/check-tests、/review-pr委派功能实现后主动调用PROACTIVELYtest-engineer 的提示词甚至给出了describe/it结构的测试代码模板和关键路径auth、payments、data handling100% 覆盖的要求而 test-checker 刻意不带 Write 工具——PR 审查阶段只应发现问题、输出建议不应改动代码。这与 插件总 README 中的安全约束呼应插件子代理运行在受限沙箱中其 frontmatter 不允许出现hooks、mcpServers、permissionMode键防止插件越权注册事件或篡改权限模型。test-checker 的 frontmatter 恰好只含name/description/tools三个合法键正是这一约束下的标准形态。从源码结构看同插件的另外两个子代理 security-reviewer.md 与 performance-analyzer.md 也采用相同的Read Grep Bash只读工具集三者共同构成 pr-review 的三专家审查阵型test-checker 专注其中的测试维度。六、安装、配置与适用前提按 pr-review README 的说明使用该插件及 test-checker需要满足三个前提Claude Code 2.1文档元信息对应 2.1.220 版本GitHub 访问权限MCP 拉取 PR 数据所需本地 git 仓库pre-review hook 的硬性校验对象。配置只需两步# 1. 设置 GitHub token export GITHUB_TOKENyour_github_token # 2. 安装插件 /plugin install pr-review安装后可用两条命令直接驱动 test-checker/check-tests # 仅测试覆盖分析 /review-pr # 综合 PR 审查含测试维度适用限制该工作流面向有 git 仓库 可访问 GitHub PR的场景若项目没有 PR 概念如纯本地实验/check-tests的覆盖率与质量分析部分仍可独立发挥作用而依赖 GitHub MCP 的变更范围定位则不生效。七、小结与引用指引test-checker 的核心价值以覆盖率 缺失用例 质量评估 边界场景四项职责把 PR 测试审查收敛为一个可委派的只读专家角色关键设计Read/Bash/Grep只读工具白名单 插件沙箱限制保证审查者不越权写码继续深入可阅读的文件test-checker 定义、check-tests 命令、review-pr 命令、pre-review Hook 源码、GitHub MCP 配置、插件机制总览。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考