为什么前端开发者不想写 e2e 测试

Source: Dev.to

（请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。）

引言

如果你因为标题而点击了这篇文章，你很可能是那些讨厌编写测试的前端开发者之一——别担心，我也和你一样。

一项最近的调查显示，大多数前端团队并不编写测试。这让我产生了以下疑问：

• 为什么前端的测试会被普遍厌恶？
• 哪些类型的测试真的重要？
• 有没有更快、更简单的方式来编写测试？

下面列出了我看到的三个主要原因，随后简要说明端到端（E2E）测试仍然必不可少，以及我们如何让它们变得不那么痛苦。

1️⃣ 编写测试感觉缓慢且充斥模板代码

大多数开发者把测试视为一种负担，而不是一种收益。当测试文件的长度超过功能本身时，总会觉得哪里不对劲。

最大的动力杀手是模板代码。
在真正关心的“用户流程”之前，你必须先完成一堆管理工作：

• 定义浏览器环境。
• Mock（模拟）API 调用。
• 处理认证状态（经典的“每个测试前都要登录”困境）。

等你把舞台搭好后，已经忘记自己想要测试什么了。没有“快速录制‑直接运行”的选项；相反，你得为无头浏览器编写基础设施代码。感觉自己在构建一个 “影子应用”，只为让真实的应用保持可测——这是一大时间消耗。

2️⃣ 开发者不知道该测试什么

如果你从事后端工作，测试通常很直接：发送输入，检查数据库或 API 响应。结果是二元且清晰的。

而前端则是一团乱麻。当你完成一个功能并坐下来编写测试时，成千上万的问题会冒出来：

• 我该测试按钮是蓝色的吗？
• 我该测试加载指示器恰好出现 200 ms 吗？
• 我该测试我的 React 组件的内部状态，还是只测试用户看到的内容？
• 如果 API 失效会怎样？我需要为每一个错误 toast 编写测试吗？

这会导致 分析瘫痪。如果没有明确的“蓝图”来指示哪些是重要的，我们只能：

1. 试图测试所有内容——导致维护噩梦，或
2. 什么也不测——因为不知所措。

在与复杂 UI 斗争了数小时后，你最不想做的就是再花三个小时去猜哪些 DOM 元素“足够重要”值得断言。这感觉就像在黑暗中投掷飞镖。

3️⃣ Front‑end moves faster than back‑end

前端代码不断变化：按钮位置会移动，布局会微调，CSS 类会被重命名。一次只需两分钟的“微小” UI 更改就可能导致整套测试全部失效。

你会发现花在更新选择器和修复“破损”测试的时间比交付新功能的时间还要多。最终，维护成本变得如此痛苦，以至于许多团队为了跟上开发速度而干脆停止编写测试。

为什么 E2E 测试很重要

在前端，E2E 测试 比单元测试更为关键。即使你对一个按钮组件实现了 100 % 的覆盖率，也无法告诉你以下情况是否会出现：

• API 加载失败。
• 一个透明的 div 意外地覆盖了整个屏幕。

归根结底，我们只关心一件事：用户的使用体验是否被破坏了？ E2E 测试模拟真实用户在真实设备上的操作，检查“Happy Path”（例如登录、点击 “Buy Now”）是否能够从头到尾顺利完成。它们是安全网，让我们可以在周五下午点击 “Deploy”，安心回家，而不必担心生产环境崩溃。

现代端到端测试的问题

你可能会认为像 Cypress 和 Playwright 这样的工具已经解决了一切。它们确实提升了体验，但根本的痛点仍然存在：

• 不稳定性 – 测试在 CI 中失败，重新运行却在没有任何代码更改的情况下通过。这会侵蚀信任：是代码出了问题，还是 API 仅仅慢了 50 ms？
• “影子应用”维护 – 即使使用现代工具，你仍然需要编写大量脚手架（环境设置、模拟、认证处理），这感觉像是一个必须与真实应用保持同步的独立应用。

Source: …

更快编写有意义测试的方法

以下是一种轻量级的做法，能够减少样板代码，专注于真正重要的内容：

1. 使用声明式测试运行器（例如内置 fixture 的 Playwright Test）。
2. 利用自动生成的选择器（data-test-id 属性），避免脆弱的 CSS 选择器。
3. 录制‑回放一次用户流程，然后让运行器生成测试骨架。
4. 只模拟必要的部分——使用网络拦截在每个测试中存根外部 API，而不是搭建完整的 mock 服务器。
5. 保持测试小而专注——每个用户故事对应一个测试（例如“登录 → 加入购物车 → 结算”）。

采用这种模式，你可以在5 分钟以内为每个功能快速搭建可靠的端到端（E2E）测试，而无需完整的“Shadow App”所带来的开销。

TL;DR

• 前端测试往往显得慢、混乱且易碎。
• 真正的价值在于验证用户旅程的 E2E 测试。
• 现代工具能提供帮助，但仍需一种能够最小化样板代码和不稳定性的策略。

尝试一下声明式、先录制再生成的方式——你可能会重新享受编写测试的过程。 🚀

现代 E2E 工具的问题

即使是今天最好的框架，仍然感觉像是为 自动化测试人员 而不是为需要快速迭代的 前端开发者 构建的。它们关注 如何 测试，却没有帮助解决保持测试可用的痛点。

常见痛点

• 绑定到实现细节 – 如果你重命名了类或更改了 data-testid，就必须在所有测试文件中逐一查找并修复。等于是同时维护两个应用。
• 学习曲线陡峭 – 要正确使用这些“现代”工具，你必须学习 async/await 模式、复杂的定位器以及如何处理无头浏览器上下文。这对只想确保 UI 不会出错的前端开发者来说要求太高。

简而言之，当前的 E2E 测试状态显得笨重且脆弱。

介绍 Symphony

在多年与不可靠的选择器斗争，并且在 Cypress 文档里花的时间比在实际代码库里还多之后，我决定打造一些更好的东西。

Symphony 是一个让端到端（E2E）测试感觉像前端工作流自然组成部分的工具，而不是一份副业。与其编写复杂的、命令式的代码去点击按钮、等待加载器，Symphony 让你以一种真正有意义的方式定义用户流程。它使用 基于 YAML 的 DSL——这基本上意味着你用简洁、可读的英文来描述测试步骤。

Project: Symphony on GitHub

为什么 Symphony 是游戏规则的改变者

• 零样板代码 – 不再需要设置浏览器上下文或庞大的 beforeEach 块。定义流程后直接运行。
• 为速度而生 – 如果构建一个功能需要 2 分钟，那么测试它就不应该花 20 分钟。
• 人人可读 – 由于测试采用简单的 YAML 格式编写，即使是产品经理或设计师也能打开测试文件，准确了解覆盖了哪些内容。

Symphony 为“懒惰”的开发者（最好的开发者类型）而构建，帮助他们在不面对维护噩梦的情况下，获得 E2E 测试的安全保障。