重思前端测试策略：为什么我从 Playwright E2E 转向组件测试？
今天深度体验了 Playwright E2E 测试，虽然它的 API 设计和工具链已经非常出色，但在实际项目中跑了一圈下来，我发现它并没有想象中那么“香”。
作为一名开发者，我们往往容易陷入“自动化万能”的陷阱。今天这篇博客，我想聊聊为什么大多数公司其实并不适合大规模引入 E2E 测试，以及我们应该如何构建更合理的测试闭环。
1. E2E 测试的三大“硬伤”
在尝试用 Playwright 覆盖「名犬鉴赏局」项目的交互流程时，我遇到了以下几个非常现实的问题：
A. 编写与维护成本的“恐怖代价”
虽然现在有 AI 辅助生成测试脚本，但它对 UI 元素的识别并不总是准确。
- 定位困境： 前端组件化（如 React/Next.js）下的 DOM 结构异常复杂。一旦 UI 样式或结构微调，原本运行良好的测试脚本就会频繁报错（Flaky Tests）。
- 交互爆炸： 简单的点击还好，一旦涉及到多级弹窗、复杂的异步加载或拖拽交互，编写脚本的成本甚至超过了开发业务逻辑本身。
B. 无法逾越的“视觉盲区”
E2E 测试的逻辑是：“只要按钮能点到，测试就通过”。 但真实场景中，页面可能会出现布局错位、元素被遮挡、或者 CSS 样式失效的情况。这些布局异常只有“人眼”才能直观识别。由于 E2E 无法做到视觉上的完全闭环，最终还是需要人工兜底，这让自动化的价值大打折扣。
C. 投入产出比（ROI）极低
对于大多数中小型项目或快速迭代的初创公司，投入大量精力去维护一套脆弱的 E2E 脚本，往往得不偿失。这也是为什么你会发现，大多数公司的前端流程中并没有引入严苛的 E2E 环节。
2. 转向性价比之选：组件/集成测试
既然 E2E 太重，我们该如何保证代码质量？答案是向测试金字塔的中层移动。
什么是组件/集成测试？
它不需要启动真实的浏览器，而是在模拟环境（如 JSDOM）中运行单个组件或模块。
为什么它更好用？
- 速度极快： 毫秒级运行，可以在开发阶段实时反馈。
- Mock 友好： 配合
MSW(Mock Service Worker)，我们可以轻松模拟接口返回，不再依赖不稳定的后端测试环境。 - 定位精准： 报错直接指向组件代码，而不是模糊的“找不到元素”。
3. 我的建议：更理性的测试方案
经过今天的复盘，我建议的前端测试策略如下：
| 测试类型 | 覆盖范围 | 建议投入 |
|---|---|---|
| E2E 测试 | 核心业务路径（如：登录、支付） | 5% (仅做冒烟测试) |
| 组件/集成测试 | 复杂业务逻辑、表单校验、高频交互组件 | 40% (性价比最高) |
| 人工/视觉走查 | 布局、审美、极端屏幕适配 | 55% (不可缺失的兜底) |
结语
技术选型永远是一场成本与收益的博弈。不要为了自动化而自动化。
如果维护测试代码的时间超过了写业务的时间，就应该果断止损。目前对于我的项目，我会将重心放在 Vitest + Testing Library 的集成测试上，而将 E2E 缩减到仅覆盖最基础的链路。
正如今天的心得：难写是一回事，难维护才是真正的死穴。