playwright

Playwright

大多数时候，要证明某个流程可用，只需现在走一遍。不需要安装任何东西，也不需要文件——用你已有的浏览器控制功能操作应用，然后汇报你看到的情况。

只有值得反复运行的流程才保存为测试。两周的冲刺里，这样的流程非常少。

先走一遍

始终默认这样做：启动应用，像普通用户一样点击走完整个流程，汇报每一步发生了什么，并明确说明是否成功。

这几乎适用于所有情况：新表单、注册流程、应该显示刚创建内容的页面。不需要规格文件、测试运行器，也不需要下载浏览器。如果构建者要求“测试”，而这样做能回答他们真正的问题，就按此操作，并告诉他们你做了什么。

何时保存测试

只有当某个流程值得在冲刺剩余时间里反复运行时，才编写并保存规格文件：

• 核心操作。 产品最重要的功能。如果它出问题，就没什么可演示的了。
• 付费流程，如果有的话——结账、升级，以及任何会收费的操作。
• 曾经出过问题的任何功能。 规则和 keep-it-working 一样：它出过问题，就可能再次出问题。

整个冲刺最多保存约三个规格文件。第四个几乎总是有人为了追求面面俱到而测试。

文件名应描述用户做了什么，而不是代码是什么：can-create-a-project.spec.ts，而不是 project-form.spec.ts。

先确认值得安装，再运行

Playwright 会下载真实浏览器——数百 MB，还要花几分钟。安装前，要明确说明这一点并确认确实值得。如果他们正在进行流程或时间紧张，就先走一遍流程，并提议之后再安装。

确认值得安装后，只安装最少内容：@playwright/test、仅 Chromium、一个配置文件和一个规格文件。不要添加额外的报告器、CI 配置或其他浏览器。冲刺期间没人会去排查仅在 Safari 上出现的故障。

登录：动笔前先一次性决定

绝不要自动化操作 Google 登录页面。 Google 会拦截自动化浏览器，任何尝试这样做的测试都会失败，而且失败表现得像是应用出了问题，其实并非如此。构建者常常因此熬上好几个通宵。

而应提前做好决定：

1. 创建一个应用可直接登录的测试用户——通过邮件链接、仅限开发环境的路由，或预置会话。
2. 登录一次，将浏览器会话保存到 storageState 文件。
3. 每项测试启动时都通过该文件恢复已登录状态。

如果项目的身份验证确实无法编写脚本，就尽早说明，并让所有已保存的测试都只覆盖未登录界面。不要等到写第三个规格文件时才发现这一点。

部署后，测试线上 URL

整个冲刺中价值最高的一次运行：推送上线后，打开生产环境 URL，执行核心操作并截图。

这能发现那种只存在于他们笔记本上、却不在 Vercel 中的环境变量——这是项目在开发环境中运行完美，却在演示当天早上彻底无法使用的最常见原因。冲刺中的其他测试都发现不了这个问题。

用简单明了的语言汇报结果，并附上截图。如果生产环境测试失败，但本地通过，要明确指出这一差异：这几乎总是配置问题，而不是代码问题。

编写能撑过一个冲刺周期的测试

界面会在两周内每天变化。紧盯标记语言的测试每天都会失效，最后被弃之不顾，这比没有测试更糟。

• 像人一样查找元素：getByRole、getByLabel、getByText。绝不用 CSS 选择器链或 Tailwind 类名——样式变更不应导致测试失败。
• 使用 Playwright 自带的断言，它们会自行等待。绝不使用 waitForTimeout。随手加的休眠会让测试在快速笔记本电脑上通过，却在演示日的 Wi-Fi 下失败。
• 每个测试规范文件只测一个流程，完整遵循一个人的操作路径。
• 测试用户看到的内容——项目出现在他们的列表中——而不是数据库里的内容。

测试只要有一次不稳定，当天就修好或删除。 一个总是误报的测试套件会让构建者学会无视红色，而无视红色的构建者比完全没有测试更糟。

不包括

不做视觉回归快照——设计仍在变化，每张快照明天都会过时。不做跨浏览器矩阵。不设覆盖率目标。不测试上述短名单之外的任何内容。

配合使用

keep-it-working 会决定某个流程是否需要测试——先查看那里。agentation 是闭环的另一半：构建者指出看起来不对的地方，而这里会验证流程是否仍然正常。checkpoint 应该已在这一切开始前保存好他们的工作。

---

这是我们自己的。编写它，是为了让第一次构建的人了解浏览器测试的价值，同时不必接手一个自己无法维护的测试套件。