ce-test-browser
everyinc/compound-engineering-plugin
对受当前分支或 PR 影响的页面运行浏览器测试。
...展开全部关于ce-test-browser
一个专用于对受拉取请求或分支变更影响的页面运行端到端浏览器测试的工作流,该工作流完全基于 agent-browser 命令行工具。 该工作流刻意避免使用任何其他浏览器自动化系统或浏览器 MCP 集成;在 Claude Code 中不使用 Chrome MCP 工具,在 Codex 中也不采用其他浏览工具。agent-browser 用于打开页面、点击元素、填写表单、截屏以及抓取渲染后的内容。 它接受一个参数,该参数可以是 PR 编号、分支名称、单词“current”或 --port 标志。
该工作流首先会验证是否已安装 agent-browser,若未安装则会停止并提示运行 /ce-setup。随后会询问是否以带界面(headed)或无界面(headless)模式运行,但在管道模式下,系统会默认采用无界面模式且不阻塞。 测试范围根据已更改的文件确定:对于拉取请求编号,使用 `gh pr view`;对于当前分支或特定分支,则使用 `git diff` 与主分支进行比较。 通过覆盖 Rails 视图、控制器、Stimulus 控制器、ViewComponents、布局、样式表、助手以及 Next.js 应用和组件路径的模式表,将更改的文件映射到可测试的路由,从而生成待测试的 URL 列表。
端口处理区分了手动模式和管道模式。它会根据显式的 --port 参数、上下文中的项目指令、package.json 中的 dev/start 脚本、环境文件,或默认值 3000 来确定首选端口,且刻意不会通过 grep 命令在文本中搜索端口。 在管道模式下,由于可能有多个代理并行运行,它会向上扫描以查找空闲端口;若未发现监听的端口,则会在后台启动开发服务器,等待时间最长为 30 秒;在手动模式下,它会直接使用首选端口,若服务器未运行,则会提示用户启动服务器。 对于每个受影响的路由,它会进行导航并捕获交互式快照(当用户选择“监视”时使用 --headed 标志),然后验证关键元素,例如页面标题或标题以及主要交互元素。使用它来验证受更改影响的页面是否仍能正确渲染和运行。
常见问题
该技能使用哪种浏览器自动化工具?
仅使用 agent-browser 命令行界面。它不使用 Claude Code 中的 Chrome MCP 工具,也不在 Codex 中使用其他浏览工具作为替代。
如果未安装 agent-browser 会怎样?
系统会提示用户运行 /ce-setup 以执行当前安装命令,安装 agent-browser 后重试;随后程序将停止运行,因为该技能在缺少 agent-browser 的情况下无法正常工作。
它如何决定要测试哪些页面?
它会从 GitHub 的 pull request 视图(针对 pull request)或与主分支的 git diff(针对分支或当前状态)中获取已更改的文件,然后使用文件模式表将这些文件映射到路由,从而构建一个 URL 列表。
开发服务器的端口如何选择?
按优先级顺序:显式的 --port 参数、上下文中的项目说明、package.json 中的开发脚本、.env 等环境文件,最后默认使用 3000。它不会通过 grep 命令在文本中搜索端口号。
管道模式有何不同?
它会跳过“带界面/无界面”的选项并默认采用无界面模式,由于代理可能并行运行,因此会向上扫描以寻找真正空闲的端口,并且如果没有开发服务器处于监听状态,则会在后台自动启动一个开发服务器。





首页
