Elementor E2E 测试中的 Playwright MCP 使用规则与实战工作流【免费下载链接】elementorThe most advanced frontend drag drop page builder. Create high-end, pixel perfect websites at record speeds. Any theme, any page, any design.项目地址: https://gitcode.com/GitHub_Trending/el/elementorElementor 是运行在 WordPress 上的前端拖拽式页面构建器其编辑器界面高度依赖 iframe 嵌套与复杂的控件交互纯靠静态代码阅读难以判断真实的 DOM、样式与网络行为。本文以仓库内 .cursor/system-prompts/test-gen/mcp-rules.md 这份 QA Agent 的 MCP 专用规则文档为骨架系统讲解在 Elementor 端到端E2E测试生成与调试过程中何时必须使用 Playwright MCP、如何执行「先观察后写码」的编码前流程、如何用 MCP 完成失败用例的根因定位并结合 tests/playwright 目录下的真实配置与页面对象源码给出可落地的运行与调试方案。为什么 Elementor 测试离不开 MCP 观察Elementor 编辑器的特殊架构决定了「读代码」与「看行为」之间存在巨大鸿沟编辑器运行在 iframe 内预览画布位于#elementor-preview-iframe框架中所有控件、样式与交互都在该 iframe 内发生。仓库的 editor-page.ts 中明确注释了辅助方法设计契约Always operate via the Editor iframe (use this.getPreviewFrame())并通过page.frame( { name: elementor-preview-iframe } )获取框架实例见 editor-page.ts。控件交互复杂视频、Google 地图、Tabs 等组件内部还存在多级嵌套 iframe需要逐层frameLocator定位。行为由前端运行时决定布局、响应式切换、样式应用等由大量前端 JS 在运行时计算静态源码无法给出确定性的选择器与时机结论。因此规则文档把「理解应用行为」列为 MCP 的第一使用场景并给出了三条典型触发条件mcp-rules.mdPhase 1 分析阶段在创建测试计划前用 MCP 手动探索 widget/feature调试阶段测试失败时用 MCP 检查真实 DOM、iframe、日志、网络请求与样式交互理解阶段需要弄清控件如何工作、元素选择器是什么、时序如何时。MCP 使用规则总览何时必须用何时不必用规则文档给出了清晰的「二分法」避免 QA Agent 对一切任务都依赖 MCPmcp-rules.mdMCP 是必需的REQUIRED场景Phase 1分析创建测试计划时必须先用 MCP 手动探索 widget/feature形成测试方案调试Debugging测试失败时必须用 MCP 检查实际 DOM、iframe、日志、网络与样式理解交互Understanding Interactions需要确认控件工作方式、元素选择器与时序时验证Validation需要核对「真实行为 vs 假设」时。MCP 非必需、可走常规工具链的场景基于已有知识编写测试代码文件操作与项目管理代码评审与重构常规项目工作流任务。关键纪律是测试失败后绝不「凭猜测」修改代码。文档明确写道Never guess a fix without reproducing via MCP未经 MCP 复现不得猜测修复方案。MCP 不可用时的降级契约当 MCP 本应使用却不可用时Agent 必须立即回复MCP_UNAVAILABLE: reason并说明自己需要 MCP 做什么。如果 MCP 报错或无法附着attach到目标应用同样回复MCP_UNAVAILABLE: reason并立即停止而不是绕开 MCP 用其他手段强行推进。这一契约保证了观察环节永不缺席。执行契约先观察后引用再写码规则文档的 Execution Contract 是一条硬性顺序约束mcp-rules.md启动 Playwright MCP 并附着到应用——注意 Elementor 编辑器位于 iframe 内附着时必须处理框架切换收集观察结果——包括 DOM、样式、网络请求、控制台输出至少完成一次成功的 MCP 观察之后才允许引用仓库中已有的辅助代码helpers若 MCP 出错或无法附着立即回复MCP_UNAVAILABLE: reason并停止。这条契约与仓库中测试辅助方法的设计思想一脉相承helpers 的定位是「通用、可复用、以 ID/值作为输入、返回 ID/locator」见 editor-page.ts而确定「到底该传什么选择器、该等什么时序」正是 MCP 观察要回答的问题。观察先行写码在后才能保证测试代码建立在真实行为之上而非主观假设。编码前测试工作流Pre-Code Testing在为目标 TC-ID 生成测试代码之前规则文档要求先完成一轮「人工走查」mcp-rules.md使用 Playwright MCP手动执行测试场景观察真实行为、选择器与交互记录发现元素选择器、时序timing、校验提示信息validation messages理解真实的用户工作流与系统响应只有在手动测试成功后才进入代码生成阶段。这一步的价值在于把「想当然的选择器」替换为「观察到的选择器」。例如 editor-page.ts 中对#elementor-preview-iframe使用frameLocator对视频、地图等组件则先等 iframe 出现再取内部元素见 editor-page.ts——这些选择器与等待策略只有在真实编辑器中观察后才能确认。编码后调试工作流Post-Code Debugging测试代码生成并运行之后若用例失败规则文档定义了标准调试闭环mcp-rules.md运行生成的测试通过 Playwright MCP失败时用 MCP 调试检查 DOM、iframe、日志、网络、样式通过 MCP 观察定位根因依据 MCP 发现修复测试代码重新运行直至通过绝不跳过失败用例也不掩盖产品缺陷——如果失败源于产品 bug应提交 BUG REPORT而不是让测试「变绿」。规则文档还强调两条收尾纪律mcp-rules.md测试生成后必须用 Playwright MCP 运行不能用其他方式替代验证宣告 done 之前必须在本地以 headless 模式再跑一次确保通过且无控制台错误console errors。从源码看headless: true正是仓库 Playwright 的默认配置见 playwright.config.ts与这条「本地 headless 复验」纪律完全一致而失败时保留 tracetrace: retain-on-failure与 CI 下保留视频见 playwright.config.ts则为 MCP 调试提供了补充证据。紧急停止协议Emergency Stop规则文档设置了一条强约束的「第一句纪律」mcp-rules.md如果在任何 MCP 调用之前即将输出任何文本STOP 并输出MCP_UNAVAILABLE: First message must be an MCP call.也就是说当会话的第一个动作本应是 MCP 观察例如 Phase 1 探索时Agent 不允许先输出分析文字再补做观察。这条协议确保了「观察先行」在整个测试生成流程中不可被口头分析所替代。在仓库中运行与调试环境准备与真实配置规则文档的 Run Debug 部分要求「运行测试」与「调试失败用例」而 Elementor 的 Playwright 测试环境需要完整的 WordPress 运行时支撑。仓库的 tests/playwright/README.md 给出了三步标准化流程启动本地 WordPress 服务器使用wordpress/envwp-env提供 Docker 化服务器与 WP CLI执行npm run start-local-server配置服务器执行npm run test:setup:playwright-sanity该命令会导入模板目前仅要求 law-firm-about、重写 .htaccess 规则并激活hello-elementor主题运行测试执行npm run test:playwright运行默认测试包指定其他包可用npm run test:playwright -- --grepnested-tabs或TEST_SUITEnested-tabs npm run test:playwright。关键运行参数来自 playwright.config.tsplaywright.config.ts 中的环境变量逻辑可直接指导 MCP 附着目标参数本地非 CICIDEV_SERVERhttp://127.0.0.1:9400http://localhost:8888TEST_SERVERhttp://127.0.0.1:9400http://localhost:8889远程调试端口9222并行索引 1 时为9223同左重试次数03workers12此外默认headless: trueBASE_URL可覆盖默认服务器地址视口默认1920x1080见 playwright.config.tsCI 下 reporter 会叠加 GitHub、list 与 allure-playwright。这些配置决定了你在本地用 MCP 观察时应该「附着到哪个 URL、以什么视口和认证态」启动浏览器。超时配置tests/playwright/config/timeouts.tstimeouts.ts 定义了调试时判断「等待多久算超时」的依据单测超时singleTest: 90_000ms全局超时global: 15 * 60_000ms断言expect: 5_000ms、动作action: 5_000ms长动作longAction: 10_000ms、重量级动作heavyAction: 30_000ms源码注释标明该值待 ED-22878 修复后降回 longAction导航navigation: 10_000ms、短等待short: 500ms、极短veryShort: 120ms。本地运行时上述数值会整体 ×2见 playwright.config.tsMCP 观察到的时序应以这些阈值为参照来设计显式等待。认证与并行测试机制parallelTest.tsparallelTest.ts 展示了 MCP 附着前必须解决的认证问题每个 worker 通过 worker 级 fixture 复用存储状态文件.storageState-{id}.json首次运行以USERNAME/PASSWORD环境变量默认admin/password调用登录接口并落盘见 parallelTest.ts。tests/playwright/README.md的 Troubleshooting 部分给出了一个与 MCP 调试高度相关的坑若你曾在localhost认证、之后把BASE_URL改成本地站点旧的 storageState 会被复用导致 Failed to fetch Nonce 错误——删除test-results/.storageState-{id}.json即可解决。MCP 观察时若发现认证态异常这是首要排查项。驱动的封装从观察走向代码仓库通过 driver-factory.ts 与 editor-driver.ts 封装了「浏览器 页面 WP 后台」的统一入口DriverFactory.createEditorDriver会打开新页面并返回EditorDriver其上下文同时暴露browser、context、page、wpAdmin、editor见 editor-driver.ts。这意味着 MCP 观察得到的选择器与交互结论可以直接映射到EditorPage上已有的通用辅助方法而不是从零发明一套定位逻辑——这正是执行契约中「先有一次成功观察再引用现有 helpers」的落点。与仓库 MCP 体系的关系值得说明的是本规则文档所讲的 Playwright MCP 属于「测试代理用来观察浏览器行为」的外部工具而 Elementor 仓库本身还内置了面向 AI Agent 的 MCP 能力体系二者在概念上互补服务端 PHP abilities位于 modules/mcp约 100 个 PHP 文件供外部 MCP 宿主通过McpAdapter调用编辑器内 JS 工具注册表位于 packages/packages/libs/editor-mcp含mcp-registry.ts、web-mcp-adapter.ts等供编辑器内 Agent如 Angie、WebMCP使用官方架构说明见 docs/atomic-builder/mcp/README.md其中明确区分了「PHP 能力跑在 WordPress 服务器端」「JS 注册表跑在浏览器编辑器内」两套独立技术栈。这套内置 MCP 体系与 QA 侧的 Playwright MCP 共同构成了 Elementor「AI 辅助开发 AI 辅助测试」的完整闭环前者让 Agent 能调用编辑器能力后者让测试 Agent 能观察编辑器真实行为。实战要点小结把规则文档与仓库源码结合Elementor 上使用 Playwright MCP 的高质量实践可总结为观察先行是铁律Phase 1 探索与失败调试都必须以 MCP 观察为起点未经复现不得猜测修复牢记 iframe 结构编辑器的真实行为都在elementor-preview-iframe内附着 MCP 后先切到框架层再逐层进入嵌套 iframe视频、地图等组件复用仓库契约观察出选择器与时序后优先套用 editor-page.ts 中「通用、可复用、返回 ID/locator」的辅助方法使用getByRole/getByTestId等稳定选择器按配置设定预期以 timeouts.ts 的阈值设计等待以 playwright.config.ts 的环境变量确定附着地址与认证态失败不掩盖产品 bug 走 BUG REPORT测试代码问题则依据 MCP 观察修复并在本地 headless 下复跑确认无控制台错误善用降级协议MCP 不可用时输出MCP_UNAVAILABLE: reason并停止绝不跳过观察环节。这套规则把「测试生成」从经验驱动的编码工作转变为「观察—记录—编码—复现验证」的证据驱动闭环是 Elementor 这类复杂 iframe 编辑器 E2E 测试稳定性的关键保障。【免费下载链接】elementorThe most advanced frontend drag drop page builder. Create high-end, pixel perfect websites at record speeds. Any theme, any page, any design.项目地址: https://gitcode.com/GitHub_Trending/el/elementor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考