Canary：Claude Code 的 E2E QA 測試框架
核心機制
- QuickJS WASM 沙箱內建完整 Playwright API
- 自動擷取：螢幕錄影 + console logs + network HAR + Playwright trace
- 單檔 report.html，打開即看所有 session
- Claude Code / Cursor / Codex 三平台插件
QuickJS WASM 沙箱：最巧妙的設計
Canary 最驚豔的技術選型是 QuickJS WASM。傳統 E2E 測試框架（Playwright、Cypress）需要 Node.js 執行環境和完整的瀏覽器驅動。Canary 把整個 Playwright 相容 API 編譯進 QuickJS WASM，讓它在 Claude Code 的沙箱內直接執行——不需要額外安裝、不需要系統權限、不需要 Docker。
這對 AI agent 場景特別重要：agent 可以 spawn 一個 Canary 測試、取得結果、根據結果修 code——全程不需要 agent 有系統級的瀏覽器存取權限。沙箱化降低了安全風險。
與傳統 E2E 框架的本質差異
| 維度 | Canary | Playwright | Cypress |
|---|---|---|---|
| 誰寫測試 | AI agent（自動） | 人類開發者 | 人類開發者 |
| 測試來源 | Code diff 驅動 | 手寫 spec 檔 | 手寫 spec 檔 |
| 執行環境 | QuickJS WASM 沙箱 | Node.js + 瀏覽器 | 瀏覽器內 |
| 可重用性 | 輸出標準 Playwright 腳本 | 本身就是標準 | 自訂格式 |
| CI 整合 | 單檔 report.html | JSON/HTML reporter | Dashboard 服務 |
Canary 不是 Playwright 的替代品——它是 Playwright 的「AI agent 前端」。傳統 QA 流程是人寫測試→機器跑；Canary 的流程是 AI 讀 diff→AI 產生測試→AI 跑→人看報告。人的角色從「寫測試」變成「審報告」。
AI Agent QA 自動化的設計模式借鏡
Canary 揭示了三個可借鏡的設計模式：
- Diff-to-Test：從 code diff 自動推斷受影響的 UI 路徑，不需要預先定義測試範圍。這對 DKY 多站部署場景有意義——改一個 sidebar 就自動測試全站導航。
- Record-then-Replay：AI agent 首次探索時成本高（推理環節），但產出的 Playwright 腳本可零成本重跑。一次投入，N 次回收。
- 單檔報告：report.html 自包含所有截圖、logs、traces，直接拖進瀏覽器就能看。不需要 CI dashboard、不需要資料庫。對小型專案特別友善。
對 dky-tools 的可能應用
| 場景 | 適用度 | 說明 |
|---|---|---|
| 多站導航迴歸測試 | 中 | 每次改 sidebar/common assets 後自動點遍六站連結 |
| 部署後 smoke test | 高 | 部署完成→自動開瀏覽器→確認首頁/子頁/工具頁正常 |
| 表單功能測試 | 低 | dky-tools 表單少，E2E 測試需求不大 |
| 視覺迴歸 | 中 | 截圖對比找 CSS 意外變動 |
最務實的應用是「部署後 smoke test」——取代目前手動 curl + MD5 比對。Canary 可以直接開啟六站首頁、截圖、檢查 console 錯誤。
限制與風險
- 91 stars，極早期專案，API 可能大幅變動
- 依賴 Claude Code 生態（非 Claude Code 使用者無法受益）
- QuickJS WASM 的 Playwright 相容性非 100%——部分進階 API 不支援
- 僅 MIT 開源但維護者未知長期投入意願
- report.html 在測試量大時（>100 次）可能過於臃腫
我的判斷
Canary 在 AI agent 輔助 QA 這個小眾場景中設計得非常好。但它目前太綁定 Claude Code 生態，且專案太新（91 stars）。對 DKY 的近期價值：借鏡 Diff-to-Test 和 Record-then-Replay 的設計模式，但不直接使用。
務實做法：在 dky-deploy-verify 的部署後驗證步驟中，手動加入一個 Playwright 腳本（不依賴 Canary），做六站 smoke test。等 Canary 成熟到跨平台（支援多種 coding agent）時再考慮整合。