发布与验证
让 AI 写 Playwright 测试：保存失败后草稿还在吗
用一次可控的失败检查错误反馈和重试。
资料核验2026.11.12 · Playwright Test · 浏览器端到端测试
一张表单正常保存没问题，断网或服务出错时却可能把用户刚写的文字清空。等待真实服务偶尔失败很费时间。Playwright 可以拦截匹配的请求并返回指定响应，把这个边界变成可重复的场景。
给 AI 的上下文与边界
让编码助手根据真实保存接口的路径和请求方法编写浏览器用例。给它后端错误响应的字段名，要求第一次只替换保存的 POST，第二次成功，列表加载请求继续使用测试服务。
把失败条件收紧到写入请求
在点击之前注册路由，只替换保存接口的 POST 响应，给它一个符合应用错误格式的 503。检查错误反馈是否可见、文本框是否仍保留草稿。然后让第二次提交返回成功，验证用户可以直接重试。
查询数据的接口尽量走真实测试服务。只替换这一个错误边界，日后更容易知道这个测试覆盖了什么。
再留一条走真实后端的保存测试，用来抓客户端和接口契约不一致的问题。
可以直接照着做的演练
在测试表单填入「周五前交稿」，点击保存。失败断言应检查这句话仍在输入框里，而不是只看失败横幅。第二次请求核对提交体确实含这句话。可以在路由回调按调用次数返回不同状态，测试结束时核对只发出了两次保存请求。
检查生成结果
- 失败时检查错误提示可见和文本原样保留。
- 重试后检查成功提示及请求带回原草稿。
- 用例中至少观察一次真实的提交动作，避免只是断言预置文案。
复查时追问一层
如果断言很快就通过，临时破坏「失败后保留文本」的实现，确认用例会变红。模拟错误负责验证前端状态，真实端到端用例负责确认接口契约，两个测试的任务边界应当写在用例名里。
给测试起名「保存失败保留草稿并允许重试」。如果首次保存按钮在等待时变成不可用，测试应等错误反馈出现再点击，避免把等待状态测成永久禁用。路由只拦保存入口，之后仍留一条真实服务的端到端用例核对协议。
