端到端测试与更新测试

单测证明逻辑，E2E 证明行为

单元测试在 Node 里跑，快是快，但它证明不了浏览器里的事：弹窗能不能打开、内容脚本注入时机对不对、权限够不够用。端到端测试（E2E）启动真实浏览器、加载真实扩展、模拟用户操作，验证的是完整行为。WXT 官方文档的结论很直接：Playwright 是写扩展端到端测试唯一靠谱的方案。

关键：加载的是构建产物

Playwright 有 Chrome 扩展的官方文档（playwright.dev/docs/chrome-extensions）。和普通网页测试最大的区别：必须用 launchPersistentContext 启动，而且传进去的是构建产物目录 .output/chrome-mv3，不是源码目录。

// e2e/extension.spec.ts
import { test, expect, chromium } from '@playwright/test';
import { fileURLToPath } from 'node:url';

const extensionPath = fileURLToPath(
  new URL('../.output/chrome-mv3', import.meta.url),
);

test('扩展弹窗可以打开', async () => {
  const context = await chromium.launchPersistentContext('', {
    channel: 'chromium',
    args: [
      `--disable-extensions-except=${extensionPath}`,
      `--load-extension=${extensionPath}`,
    ],
  });
  // 拿到扩展 ID 后访问弹窗页面，断言内容渲染
  await context.close();
});

几点注意：

1. 跑 E2E 前先 wxt build，保证产物目录存在（如 §38 所述）；
2. 扩展只能跑在 Chromium 系浏览器，且要求持久化 context；
3. 无头模式要用新版 headless（—headless=new），旧模式加载不了扩展；调试时直接 headed 更直观；
4. service worker 的日志可以在 context 里监听，比肉眼看得快。

E2E 适合验证的场景：弹窗与选项页能打开、内容脚本在匹配页面注入、设置写入 storage 后重启扩展仍在。这类用例不用多，覆盖核心链路即可。

更新场景一：权限变化

扩展更新时，如果 permissions 或 host_permissions 变了，浏览器会暂时禁用扩展，等用户接受新权限。这在发布新版时是真实风险：用户可能就此流失。

怎么测自己的更新会不会触发禁用？

• Chromium：用 Google 官方的 Extension Update Testing 工具（GoogleChromeLabs/extension-update-testing-tool），模拟从旧版本升级到新版本；
• Firefox：参考官方文档 Test Permission Requests 页面；
• Safari：没有现成工具，只能人工小心验证。

更新场景二：update 事件

扩展更新后想跑一段逻辑（迁移存储数据、清理旧缓存、弹个更新说明），挂在 runtime.onInstalled 上：

browser.runtime.onInstalled.addListener(({ reason }) => {
  if (reason === 'update') {
    // 从旧版本升级上来，这里做数据迁移
  }
});

测试它有三种办法：

1. 逻辑简单：抽成纯函数写单元测试（如 §36 所述），最快；
2. 手动触发：开发模式暂时去掉 if 判断，在 chrome://extensions 里点「重新加载」，回调就会执行；
3. 模拟升级：用 Google 的更新测试工具从旧版本升级到新版本，验证真实路径。

E2E 跑起来慢、环境脆，别把每个单元逻辑都塞进去——只覆盖「跨环境协作」这条主线。

CI 里跑 E2E 记得缓存浏览器下载，避免每次构建都重新拉 Playwright 的浏览器二进制。

小结

• 单元测试、端到端测试、更新测试三者分工不同：E2E 证明扩展能跑，更新测试证明升级不翻车。
• 版本升级是最容易被忽略的测试场景，建议把「旧数据 → 新逻辑」的迁移用例固定下来。