发布与验证
让 AI 写 Playwright fixture：谁建草稿，谁清理
用 fixture 明确谁创建、谁删除。
资料核验2026.11.12 · Playwright Test · 浏览器端到端测试
几条用例都在编辑一份预置草稿。它们单跑通过，并行时却互相覆盖。把「有一份草稿」变成 fixture，让每条测试先拿到专属记录，问题会比调整运行顺序好查。
给 AI 的上下文与边界
给助手测试后端的数据创建和删除接口，要求每条用例创建自己的记录，fixture 只返回 ID 和必要字段，清理只按精确 ID 执行。请它画出一条断言失败时的执行路径。
夹具只负责准备和清理
通过测试接口创建带唯一标记的草稿，把 ID 交给测试。用例只关心编辑行为。结束时按 ID 清理资源，失败后也执行清理路径。清理不能按标题模糊批删，避免影响其他并行用例。
用两条相同逻辑并行跑一次，检查它们确实编辑了不同 ID。再人为让其中一条断言失败，查看后端是否仍能清掉两份临时数据。
只有准备代价很高、又能保证只读的资源，才考虑在 worker 范围共享。
可以直接照着做的演练
夹具返回 draftId，用例只拿它改标题。给两个并行任务的草稿相同标题，故意让一条断言失败，然后按各自 ID 查临时库。若清理依赖标题，样本会让误删风险显现。
检查生成结果
- 两条并行用例看到不同 ID。
- 主动让一条测试失败后临时数据仍被清理。
- 清理失败能定位到记录和当前用例。
复查时追问一层
如果夹具用模糊标题批量删除，风险来自测试共享了数据空间。需要公共样本时明确它只读，写测试仍独占自己的资源。外部测试环境的清理失败应有记录，便于下次排查。
如果失败发生在 fixture 准备过程，仍可能已经创建了一半数据。让助手安排创建成功后就登记 ID，随后用可靠的清理阶段释放。若测试需要调试失败现场，可以先保存脱敏日志，业务测试数据仍按约定清理。
