05 测试与评估策略

学习目标

本章要解决什么问题：Cline 如何构建多层次测试体系？系统提示词为什么要用快照测试？E2E 测试如何模拟 VS Code 扩展的真实交互？

---

项目实践

多层次测试架构

单元测试

src/test/ 下的 *.test.ts 文件覆盖工具执行、上下文管理、审批逻辑等：

• 工具 handler 的输入输出验证
• 自动审批策略的边界条件
• 上下文截断的正确性

测试命令：npm run test 或 npm run test:unit

快照测试

__tests__/ 目录使用 snapshot 测试验证系统提示词：

# 伪代码：快照测试
test("generic variant should match snapshot", () => {
    const prompt = buildSystemPrompt("generic")
    expect(prompt).toMatchSnapshot()
})

为什么用快照测试？ 系统提示词的正确性很难用传统断言验证。快照测试将整个提示词保存为基准，修改提示词时自动生成 diff，便于 code review 检查意外变化。

E2E 测试（Playwright）

src/test/e2e/ 使用 Playwright 模拟真实用户交互：

• 打开 VS Code 扩展的 Webview
• 输入提示词
• 验证 Agent 执行了正确的工具调用
• 检查 UI 渲染结果

为什么用 Playwright？ VS Code 扩展的 Webview 是一个 Chromium 渲染的页面，Playwright 可以模拟真实用户操作（点击、输入、滚动），验证从 UI 到 Agent 执行的完整链路。

Evals 基准测试

evals/ 目录包含基准测试：

子目录	用途
cline-bench	Cline 专属能力基准测试
benchmarks	通用 Agent 能力评估
smoke-tests	冒烟测试，快速验证核心功能

评估维度：代码生成质量、工具调用正确率、多步任务完成率、上下文管理效率。

CI 集成

测试在 GitHub Actions 中自动运行：

• PR 创建时运行所有单元测试和快照测试
• E2E 测试在合并到 main 分支时运行
• Evals 定期运行，追踪 Agent 能力变化

---

问题与规避

陷阱	场景	对策
快照测试误报	格式化或空格变化导致快照不匹配	审查快照 diff，确认是预期变化后更新
E2E 测试不稳定	VS Code 版本更新导致 Webview 变化	使用 Playwright 的 waitFor 等待元素稳定
Evals 结果不可复现	LLM 输出有随机性	多次运行取平均值，设置合理的方差阈值

---

设计取舍

快照测试 vs 断言测试

方案	优势	代价
快照测试	整体对比、变化直观	难以定位具体问题
断言测试	精确验证特定条件	需要编写大量断言

Cline 对系统提示词用快照测试，工具逻辑用断言测试。提示词是整体性内容，快照测试最适合验证整体结构；工具执行是逻辑性内容，断言测试更精确。

Playwright vs VS Code 原生测试 API

方案	优势	代价
Playwright	模拟真实用户行为、跨平台	需要了解 Playwright API
VS Code 原生 API	与 VS Code 集成紧密	测试的是 API 而非用户体验

Cline 选择 Playwright，因为 E2E 测试的核心目标是验证用户体验，而非 API 正确性。

---

参考来源

• Cline 源码：apps/vscode/src/test/
• Cline 源码：apps/vscode/__tests__/
• Cline 源码：evals/