7.3 测试金字塔：从单元测试到 E2E

7.3 测试金字塔：从单元测试到 E2E

本节摘要：Electron 应用的测试按金字塔分层：数量最多的纯逻辑单元测试（跑得飞快）、中间层的进程内集成测试（preload 桥契约、主进程模块）、塔尖的 E2E（驱动真实应用走关键路径），生产期再以崩溃报告与结构化日志补上远程诊断的眼睛。本节讲分层策略、各层的工具选型与写法、以及崩溃报告的接入。

分层：钱花在刀刃上

测试策略的第一决策是资源分配。金字塔的经济学逻辑很直白：单元测试毫秒级、反馈最快、数量应该最大；E2E 最接近真实但最慢最脆，只保卫关键路径；集成测试居中，专守 Electron 特有的接缝（IPC 桥、主进程模块）。倒金字塔（一堆 E2E、没几个单元测试）是常见的反模式——每次跑测试半小时，脆断没人修，最后整个团队对红灯麻木。

图：Electron 应用的测试金字塔

塔基：单元测试

Electron 的单元测试没有特殊之处——纯逻辑就按 Node 工程测，前端组件就按前端工程测（主流测试框架配 jsdom 环境）。真正值得强调的是什么该被设计成可单测的：时间与随机性注入化（要测超时逻辑就把时钟函数作为依赖传入）、状态机显式化（复杂界面状态抽成纯函数的状态转移）、IPC 处理器瘦身（handle 只做参数校验与转发，业务下沉到可独立测试的模块）。这三条让大部分逻辑摆脱对 Electron 运行时的依赖。

// 可单测的设计示例：业务逻辑与 Electron 解耦
// 纯逻辑模块：同步重试的退避计算
function nextRetryDelay(attempt, baseMs = 1000, maxMs = 300_000) {
  const capped = Math.min(baseMs * 2 ** attempt, maxMs);
  return capped * (0.8 + Math.random() * 0.4);   // 抖动，防同步风暴
}

// 单元测试：断言边界行为，毫秒级
test('退避有上限且带抖动', () => {
  const d = nextRetryDelay(20);
  expect(d).toBeLessThanOrEqual(300_000 * 1.2);
  expect(d).toBeGreaterThanOrEqual(300_000 * 0.8);
});
​

塔身：进程内集成测试

Electron 特有的接缝值得专门一层。桥契约测试：3.2 节的共享类型保证了编译期对齐，集成测试验证运行期行为——真实起一个 Electron 运行时，加载 preload，断言暴露的接口调用后确实触发了对应的 handle。主进程模块测试：数据服务层（7.2 节的 SQLite 封装）用内存库跑增删改查与迁移脚本的回归。这层测试的价值在于捕获"配置正确但行为漂移"的问题，比如某次升级后 handle 的错误不再正确跨进程传播。

# 集成层的典型命令流（CI 中）
$ npm run test:unit        # 3 秒，几百条
$ npm run test:integration # 40 秒，起真实运行时，桥契约 + 数据层
$ npm run test:e2e         # 8 分钟，仅冒烟与关键路径
​

塔尖：E2E

E2E 用 Playwright 或同类工具驱动真实应用：启动构建产物、模拟点击输入、断言界面状态与落盘结果。两条纪律：只测关键路径（登录、核心业务的完整往返、更新提示的出现），不做细节断言（像素级对比那种脆断大户）；显式等待取代休眠——等元素出现、等事件到达，不写固定延时，后者是 E2E 抖动的头号来源。

生产期的眼睛：崩溃报告与日志

测试管住了发布前，生产期要靠两只眼睛。崩溃报告：Electron 内置 crashReporter，把原生崩溃的小型转储上报到收集服务，配符号化后可定位到出错的代码位置；第三方（如 Sentry）在转储之外还能接住 JS 异常，把渲染进程与主进程的错误统一归集。结构化日志：3.2 节埋的伏笔在此兑现——带级别与上下文的日志落盘用户数据目录，远程诊断时请用户导出一份即可还原事故现场。

// 主进程：崩溃报告的接入要点
const { crashReporter } = require('electron');

crashReporter.start({
  uploadToServer: true,
  submitURL: 'https://crash.example.com/minidump',
  extra: { appVersion: app.getVersion(), platform: process.platform }
});
​

隐私红线别忘：上报内容只含技术信息（堆栈、版本、平台），不含用户数据；用户可关闭上报，这是多地合规的底线要求。

案例：给一个裸奔项目补测试体系

背景：一个上线两年的内部工具，零测试，每次发版靠手工回归，一次数据库迁移 bug 导致全员半天无法使用，管理层终于批了治理时间。

操作：按金字塔从底往上补。先给纯逻辑补单测（历史欠账最多的时间处理与权限计算模块，两周补到七成覆盖）；再写桥契约与数据层迁移的集成测试（重点防住这次事故的同类型问题——迁移脚本在空库、旧库、脏库三种初始状态下的行为）；最后挑五条关键路径上 E2E。生产期接入崩溃报告与结构化日志。

结果：随后半年的四次发版，两次在集成层就拦下了迁移与 IPC 契约类问题；一次线上崩溃经符号化定位到具体模块，两小时出修复版，而此前同类问题的平均定位时间是一天半。

解读：补测试的顺序设计（底厚顶尖）与投入产出直接挂钩——单测与集成测试拦下的问题占比远高于 E2E，但 E2E 保卫的是"发版敢按按钮"的信心。变式：如果团队只有一周预算，就做集成层那一小块（桥契约加数据迁移回归），对 Electron 应用而言那是性价比最高的那块砖。

本节要点回顾

• 金字塔经济学：单元最多、集成守缝、E2E 只走关键路径，倒金字塔是反模式；
• 可测性设计：时钟与随机注入、状态机显式化、处理器瘦身，让逻辑摆脱运行时依赖；
• 集成层价值：桥契约与迁移回归，专防"配置对但行为漂移"；
• E2E 纪律：显式等待取代休眠，细节断言是脆断之源；
• 生产眼睛：崩溃报告加结构化日志，隐私红线是用户数据不上报、可关闭。

质量体系就位，最后一节把视野拉高：向 VS Code 这座 Electron 丰碑取经，聊聊架构模式与企业级实践。