我不想要只能证明函数工作的测试集，而想保护那些一旦坏了就会造成损害的工作流。
这不意味着每条规则都需要浏览器测试。浏览器有价值，但更慢、更脆弱。可以直接用 Vitest 测产品规则时，我通常从那里开始。
例如没有标题的请求不能提交：
test("cannot submit an empty request", async () => {
await expectSubmitRequest({ title: "" }).rejects.toThrow("Title is required");
});这是简化测试，展示规则应在哪一层验证。检查空标题无效，不必打开浏览器；服务测试更快，也更贴近问题。
Playwright 回答另一个问题：用户能否完成整个路径，打开页面、填写表单、提交、跟随跳转并看到新状态？
它能发现连接问题：表单缺少 name、跳转错误、loader 错误、权限问题，以及服务测试看不到的界面状态。
浏览器测试应聚焦关键路径：创建最常创建的对象、编辑常用对象、提交或批准流程、看到证明成功的状态，再覆盖一个重要权限或失败路径。
我曾因为 E2E 更贴近产品，就把太多测试放进去，结果变成缓慢清单。失败时不清楚究竟是规则、选择器、种子数据还是浏览器不稳定。
更合理的分工是 Vitest 覆盖规则、服务、校验、格式和小型集成边界；Playwright 覆盖少数确实需要全栈参与的用户旅程。
截图和 trace 对 CI 失败尤其有帮助，因为没有人在看浏览器。但私有截图应保持私有，公开写作宁愿用小演示应用，或不放截图。
测试边界也需要维护。服务太薄，服务测试证明不了多少；UI 拥有太多逻辑，浏览器就成为唯一测试方式。这通常说明代码边界需要改进，而非应该增加更多浏览器覆盖。
通过测试不代表产品绝对正确，只代表某些预期仍成立。价值在于选择与用户风险相符的预期。
服务测试：无效输入不能提交
服务测试：有效提交改变状态
服务测试：无权限用户被拒绝
浏览器测试：用户创建、提交，并看到已提交状态这不是穷尽所有情况，而是实用起点：保护规则和路径，同时不把每种细小变化都变成完整浏览器测试。