用Playwright驱动真实浏览器，写前端组件的E2E测试

前端组件测试，长久以来都有一个尴尬的处境：单元测试跑得飞快，却总在真实环境里翻车；手工测试最真实，但费时费力还容易遗漏。直到 Playwright 出现，这个局面终于有了改观——它直接驱动真实浏览器，让你的测试跑在用户真正使用的环境里。

从 jsdom 到真实浏览器：质的飞跃

很多前端团队用过 Jest + Testing Library，配合 jsdom 模拟 DOM 环境。它的优点是快，但缺点也很明显：jsdom 不是真正的浏览器。它不执行布局，不渲染像素，很多浏览器 API 缺失或表现不一致。于是你常常会遇到这种情况——单测全绿，一上线就白屏。

Playwright 的思路完全不同。它通过 CDP 协议（或 WebDriver）真实启动 Chromium、Firefox 或 WebKit，你的代码在真正的浏览器内核中运行。这意味着什么？意味着你的测试能捕获到真实的事件派发、真实的样式计算、真实的滚动行为，甚至能验证截图里的像素级细节。

测试的视角应该是用户，不是实现

写组件测试，最忌讳的是把测试写成实现细节的复读机。比如断言某个内部 state 是否正确、某个方法是否被调用——这些测试一旦重构就碎，而且对用户毫无意义。

Playwright 鼓励你站在用户视角写测试。用户不关心你的组件内部怎么管理状态，他们关心的是：点击按钮后，页面上是否出现了预期内容。

await page.goto('/components/button');
await page.getByRole('button', { name: '提交' }).click();
await expect(page.getByText('提交成功')).toBeVisible();

不需要知道组件的 DOM 结构，不需要等待固定的毫秒数，不需要 mock 一堆内部方法。用户能看到的，就是你要断言的。

这里背后的一项是 Playwright 的自动等待机制。它会在元素可交互、可点击、可见之后才执行操作，这大大消除了测试中常见的 flaky 问题。

一个工具，覆盖从开发到联调到修复

Playwright 最有吸引力的还有一个点：它不只是测试工具，更是一个完整的工作流。

开发时用 `playwright codegen`，你可以在浏览器里点点点，它自动帮你生成测试代码。联调时用 trace viewer，每次跑完测试都能回放逐步的执行录像，每个操作对应的 DOM 快照、网络请求、控制台日志一目了然。排查问题时，测试失败会自动截图，甚至录屏。

这直接改变了测试的调试体验。以前写测试，失败了只能靠 console.log 猜。现在打开 trace 文件，能看到那个失败瞬间页面到底长什么样，UI 状态如何，网络返回了什么。

把测试跑在矩阵上，而不是单点上

真实浏览器的价值，还体现在跨浏览器兼容性上。Playwright 支持同一套测试跑在三种浏览器引擎上，只需要配置一下 project。

projects: [
  { name: 'chromium', use: { browserName: 'chromium' } },
  { name: 'firefox', use: { browserName: 'firefox' } },
  { name: 'webkit', use: { browserName: 'webkit' } },
]

这意味着你在本地开发时就能发现 Safari 里的 flex 布局问题、Firefox 里的事件兼容问题，而不是等 QA 提 bug 才知道。对于组件库的维护者来说，这套机制尤其有价值——你发布一个版本，可以同时对全量组件跑一遍跨浏览器冒烟测试。

还有移动端模拟。Playwright 可以模拟 iPhone 的视口、触摸事件、网络节流，这让移动端组件的回归测试不再依赖昂贵的真机实验室。

社区的声音

前端社区对这个工具的接纳度非常高。这不是没有原因的——它解决了长期困扰大家的痛点：测试与真实环境脱节、调试困难、跨浏览器覆盖成本高。

有人担心 Playwright 测试跑得慢，毕竟要启动真实浏览器。但换个角度想：一个缓慢但可靠的真实测试，远比一百个飞快却虚假的 mock 测试有价值，也更务实。更何况，Playwright 支持并行执行和测试分片，在实践中，几百个用例跑完也就几分钟的事。

前端组件的质量不应该靠运气。如果你还在靠手工点击验证组件行为，或者被 jsdom 里的诡异差异折磨，不妨试着把 Playwright 引入你的项目。让测试跑在真实浏览器里，让问题在发布前现形——这种踏实感，值得拥有。