ce-test-browser

關於ce-test-browser

一套工作流程，專門用於針對受拉取請求或分支變更影響的頁面執行端到端瀏覽器測試，且僅使用 agent-browser 命令列介面（CLI）。 此工作流程刻意避免使用任何替代性的瀏覽器自動化系統或瀏覽器 MCP 整合；在 Claude Code 中不使用 Chrome MCP 工具，而在 Codex 中則不以其他瀏覽工具取代。agent-browser 用於開啟網頁、點擊元素、填寫表單、擷取螢幕截圖，以及擷取渲染後的內容。 它接受一個參數，該參數可以是 PR 編號、分支名稱、關鍵字「current」，或是 --port 標誌。

此工作流程會先驗證 agent-browser 是否已安裝，若未安裝則會停止執行並提示執行 /ce-setup。接著會詢問是否以 headed 或 headless 模式執行，惟在管線模式下，預設會直接以 headless 模式執行而不阻塞。 測試範圍是根據變更的檔案來決定，若為 Pull Request 編號則使用 `gh pr view`，若為「current」或某個分支，則使用 `git diff` 對比 `main` 分支。 透過涵蓋 Rails 視圖、控制器、Stimulus 控制器、ViewComponents、佈局、樣式表、輔助函式，以及 Next.js 應用程式與元件路徑的模式表，將變更的檔案映射至可測試的路徑，從而產生待測試的 URL 清單。

埠號處理機制區分手動模式與管線模式。它會從顯式的 --port 參數、當前專案的指令、package.json 中的 dev/start 腳本、環境設定檔，或預設值 3000 中確定首選埠號，並刻意避免透過 grep 指令從描述性文字中搜尋埠號。 在管線模式下，由於多個代理程式可能並行執行，系統會向上掃描尋找可用端口；若無端口處於聆聽狀態，則會在後台啟動開發伺服器，並等待最多 30 秒；在手動模式下，則直接使用首選端口，若伺服器尚未運行，則會要求使用者啟動伺服器。 針對每個受影響的路由，它會進行瀏覽並擷取互動式快照；若使用者選擇「監看」模式，則會使用 --headed 旗標，隨後驗證關鍵元素（例如頁面標題或標題標籤，以及主要互動元素）。可藉此驗證受變更影響的頁面是否仍能正確渲染並正常運作。

常見問題

此技能使用哪種瀏覽器自動化工具？

僅使用 agent-browser 命令列介面（CLI）。它不會使用 Claude Code 中的 Chrome MCP 工具，也不會以 Codex 中的其他瀏覽工具作為替代。

若未安裝 agent-browser 會發生什麼情況？

系統會提示使用者執行 /ce-setup 以取得當前安裝指令，安裝 agent-browser 後重試；若未安裝，程式將停止運作，因為此技能無法在缺少 agent-browser 的情況下運作。

它如何決定要測試哪些頁面？

它會從 GitHub 的 PR 檢視頁面（針對 PR）或與 main 分支的 git diff（針對分支或當前版本）取得已變更的檔案，接著透過檔案模式表將這些檔案映射到路由，以建立一組 URL 清單。

開發伺服器的埠號如何選定？

依據優先順序：明示的 --port 參數、專案中的相關指示、package.json 中的開發腳本、.env 等環境設定檔，最後預設為 3000。它不會透過 grep 從文字說明中搜尋埠號。

在管道模式下有什麼不同？

它會跳過「帶介面/無介面」的選擇並預設為無介面模式，由於代理程式可能並行執行，因此會向上掃描以尋找真正空閒的埠號，若沒有開發伺服器正在聆聽，則會在背景自動啟動開發伺服器。