Continue 的自动化测试覆盖审查：深入解析 Test Coverage 代理（`.continue/agents/test-coverage.md`）

本文以 Continue 仓库中自带的测试覆盖审查代理 .continue/agents/test-coverage.md 为核心，完整拆解其审查标准、豁免范围与执行策略，并结合仓库中真实存在的测试基础设施（Jest/Vitest 双轨配置、测试脚本与 fixture 体系）说明该代理判断依据从何而来。读完本文，你将掌握 Continue 如何在 PR 评审流程中用 LLM 代理把关"新功能是否配得上足够的测试"，以及如何在自己的项目中参照这套模式配置一个可落地的测试覆盖检查 Agent。

一、它是什么：一个定义在仓库里的 PR 测试覆盖审查 Agent

test-coverage.md 是一个标准的 Continue Agent 定义文件，位于仓库的 .continue/agents/ 目录下，与同目录的 breaking-change-detector.md、dependency-security-review.md、error-message-quality.md、input-validation.md 等代理并列。它的 YAML front matter 只有两行：

---
name: Test Coverage
description: Ensure new functionality includes corresponding tests
---

name 是代理的展示名，description 则是代理被调用时的自述。正文部分则是一份写给 LLM 的审查指令：Review this pull request to determine if new functionality has adequate test coverage.（审查这个 Pull Request，判断新增功能是否有足够的测试覆盖）。

这类文件本身不是代码，而是"以自然语言编写的审查逻辑"——当 Continue 的子代理机制（如 CLI 中通过 cn -p 启动的后台子代理，见 .continue/prompts/sub-agent-background.md）加载该 Agent 时，LLM 会以这份文档为行为准则去分析 PR diff，最终产出"缺什么测试、为什么需要"的评审意见。

二、审查标准：什么情况下应当期待有测试

文档给出了四类"必须期待测试"的场景，这是该 Agent 判断的核心依据：

2.1 新导出的函数或类

任何被导出、会被代码库其他部分使用的新公共函数、类或模块，都应当至少包含基础的单元测试，且要覆盖三个层面：

• Happy path（正常路径）：预期输入产生预期输出；
• Edge cases（边界情况）：空输入、null/undefined、边界值；
• Error cases（错误场景）：非法输入应当抛出或返回恰当的错误。

2.2 新的 CLI 命令或子命令

Continue 的 CLI（extensions/cli/）是活跃开发区，因此新增命令或子命令应满足：

• 冒烟测试：验证命令能正确注册并运行；
• Flag 解析与校验测试；
• 预期输出格式测试。

仓库中的 extensions/cli/vitest.e2e.config.ts 印证了 CLI 测试确实分层的：e2e 配置将 include 限定在 src/e2e/**/*.test.ts，且单测配置 extensions/cli/vitest.config.ts 显式 exclude 了 **/*.e2e.* 与 **/e2e/**——这正好对应文档中"冒烟测试 + 输出格式测试"与更深层行为测试相分离的期望。

2.3 Bug 修复

如果 PR 是修 bug，就应当有一个回归测试：

• 能复现原始 bug 的条件；
• 能验证修复确实生效。

这是经典的"红转绿"回归测试要求，Agent 在评审时会专门检查 diff 中是否存在这样成对出现的修复与测试。

2.4 新的 API 端点或处理器

应当有集成测试，覆盖：

• 成功的请求/响应；
• 非法输入的错误响应；
• 认证/授权（如适用）。

三、豁免清单：什么情况下不要求测试

与"必须期待"相对的是一份明确的豁免清单，Agent 对落入以下类别的 PR 应"do nothing"（不做任何评论）：

• 纯文档变更；
• 配置文件变更（YAML、JSON、Markdown）；
• CSS/样式变更；
• 依赖更新（除非改变了行为）;
• Agent 定义文件本身（.continue/agents/*.md）；
• 不改变行为的纯重构（现有测试应当继续通过）；
• 已被现有测试完全覆盖的内部实现变更。

这份清单的价值在于给 LLM 划定了"不许过度反应"的边界——它防止代理对文档 PR、配置 PR 也机械地要求补测试，避免评审噪音。值得注意的是，这条豁免规则形成了自我指涉：test-coverage.md 文件自身作为 .continue/agents/*.md 的一部分，修改它是不需要任何测试的。

四、执行策略：只提意见，不动手写测试

文档的 ## What to Do 一节规定了代理的行为红线，这是整份 Agent 定义中最体现工程权衡的部分：

1. 发现缺测就评论：如果新功能缺乏测试，在 PR 上留一条评论，说明"应当测什么、为什么"；
2. 绝不自己写测试：Do NOT write tests yourself. The author knows the intended behavior best.——作者最清楚预期行为，LLM 代笔的测试可能把错误语义固化下来；
3. 测试不完整要指出缺口：如果 PR 带了测试但明显不全（缺边界用例、缺错误用例），要指出具体缺了什么；
4. 豁免类 PR 保持沉默。

"只诊断、不开刀"的设计把 LLM 定位成评审者而非实现者，规避了 Agent 直接改代码带来的行为漂移风险，也保证评审意见的责任主体仍是 PR 作者。

五、判断依据从何而来：仓库真实测试基础设施对照

文档末尾的 ## Test Infrastructure Reference 给出了代理判断"测试写在哪、用什么框架"的依据：

模块	框架与文件约定
Core	Jest（*.test.ts）+ Vitest（*.vitest.ts），位于 core/
GUI	Vitest（*.test.ts），位于 gui/src/
CLI	Vitest（*.test.ts、*.e2e.test.ts），位于 extensions/cli/
Packages	各 packages/*/ 目录下的 Vitest

这张表不是凭空写的，仓库中的实际配置可以逐项印证：

• Core 双轨制：core/vitest.config.ts 中 include: ["**/*.vitest.ts"]，而 core/jest.config.js 中 testMatch: ["**/*.test.ts"]——两套框架按文件后缀严格分流，互不干扰。core/package.json 的脚本也与之对应：test 脚本为 cross-env NODE_OPTIONS=--experimental-vm-modules jest（ESM 场景下 Jest 需要 --experimental-vm-modules 标志），另有独立的 vitest: vitest run 脚本。
• Jest 侧的运行细节：core/jest.config.js 配置了 maxWorkers: 1（等价于 --runInBand）、testTimeout: 10000、ESM 预设 ts-jest/presets/default-esm，并通过 globalSetup: "<rootDir>/test/jest.global-setup.ts" 和 setupFilesAfterEnv 注入测试环境。
• CLI 侧：extensions/cli/package.json 的 test 脚本即 vitest run，配合上述两个 Vitest 配置文件实现单测与 e2e 分离。
• Packages 侧：packages/ 下多个包（fetch、openai-adapters、terminal-security 等）的 test 脚本均为 vitest run，而个别包（config-types、continue-sdk、llm-info）目前声明为 No tests to run——Agent 判断时应对这些包的"缺测试"保持宽容。

此外，仓库还通过规则文件约束测试的书写方式，Agent 在指出"测试缺口"时可据此引用具体规范：

• .continue/rules/test-running-guide.md 给出各目录的跑测命令（如 cd gui && npm test、cd core && npm test / cd core && npm run vitest），并明确说明项目正在向 Vitest 迁移，新建测试应优先使用 Vitest；
• .continue/rules/unit-testing-rules.md 规定测试结构：写顶层 test() 函数、不要使用 describe() 块、测试描述中要包含被测函数名。

也就是说，这个 Agent 的审查意见实际上受三层文档共同约束：Agent 定义本身（测什么）+ 规则文件（怎么测、测在哪）+ 各包测试配置（框架分流）。

六、配套生态：从"审查缺测"到"生成测试"的完整闭环

.continue/ 目录并不只有审查这一侧。仓库同时提供了测试生成的提示词模板 .continue/prompts/core-unit-test.prompt，它与 test-coverage Agent 形成互补：

• 生成侧要求使用 Jest 29、ESM 导入、测试文件与被测文件同路径仅扩展名换成 .test.ts，并明确指定了可用的测试基建：@core/test/jest.global-setup.ts 初始化临时全局目录，@core/test/testDir.ts 提供 setUpTestDir/tearDownTestDir 工作区目录工具；
• .continue/prompts/core-unit-test.prompt 还指定了 fixtures 体系——从 core/test/fixtures.ts 导入 testIde（IDE/工作区操作）、testConfigHandler（配置需求）、testLLM（任意 ILLM/BaseLLM 需求，通过设置 completion 属性控制返回内容）等，并要求不要 mock 这些 fixtures（除 jest.spyOn 外）、优先 mock 第三方模块。

这条链路体现了一个值得借鉴的分工：生成模板负责"按仓库约定把测试写出来"，Agent 负责"在 PR 上核查测试是否到位"。两者共享同一套基础设施约定，因此生成出的测试天然能通过覆盖审查，审查指出的缺口也天然可以用生成模板补齐。

七、可借鉴的模式总结

回到 .continue/agents/test-coverage.md 本身，这份不到 60 行的文件展示了 LLM Agent 定义中几个可复用的设计手法：

1. 正向清单 + 负向豁免双清单：先用四类场景界定"必须有测试"，再用七类场景界定"不必有测试"，让 LLM 的判断收敛在明确的边界内；
2. 行为红线优于能力授权：明确规定"不许自己写测试"，把代理限定在评审角色上；
3. 给出可核对的事实基线：Test Infrastructure Reference 让代理的每条意见都能落到"该在哪个目录、用哪个框架"的具体判断上，而不是泛泛而谈；
4. 与仓库规则体系联动：Agent 文档、.continue/rules/ 规则文件、各包 package.json 脚本三者一致，保证代理输出与真实工程约定不脱节。

对于其他项目，这套模式可以直接迁移：在 .continue/agents/（或等效的 Agent 目录）中定义一个测试覆盖审查 Agent，写明本仓库的测试框架分流规则与豁免清单，再配合一条"禁止代写测试"的行为红线，即可获得一个低噪音、可解释的 PR 测试评审助手。