Playwright Canvas Testing Limitations¶
概念概覽
Canvas 的根本限制¶
核心知識¶
Canvas 的根本限制¶
不管用哪個 Playwright 工具，PixiJS canvas 的內容都**無法被 DOM selector 檢查**：
- codegen 錄不出 canvas 內的操作
- @playwright/cli 的 YAML 快照也抓不到 canvas 像素內容
- 只能做截圖比對（pixel diff），無法做語義斷言
Playwright CLI vs 一般 Playwright API¶
兩者在 Canvas 限制上**沒有差異**，Canvas 不屬於 DOM 樹，所有 selector-based 操作都失效。Playwright CLI 的優勢在於： - YAML 格式的測試腳本更易讀 - 適合非工程師維護測試
但對 Canvas 內容的測試能力與一般 Playwright API 相同，都無法突破 Canvas 的 DOM 不可見性。
Cocos TypeScript 引擎 vs PixiJS¶
從 AI agent 開發角度調研： - Cocos TypeScript：組件基於 Scene Graph，有 Node/Component 結構，理論上更易被 AI 理解和操作 - PixiJS：純渲染庫，結構更扁平，所有互動邏輯需自行建構 - 對 E2E testing 而言，兩者都渲染到 Canvas，Playwright 限制相同 - Cocos 的優勢在於其編輯器和組件系統，而非測試可觀測性
經驗教訓¶
-
Playwright CLI 對 Canvas 的限制與一般 Playwright API 完全相同，不要期望切換工具能解決 canvas 不可見問題
-
PixiJS 的 E2E 測試實際上只能做截圖 diff + 行為側錄（網路請求、事件），無法做 DOM 語義斷言
-
Cocos TypeScript 的 Scene Graph 結構更適合 AI agent 理解，但同樣渲染到 Canvas，E2E 測試能力沒有本質差異
常見陷阱¶
-
不要嘗試用 Playwright selector 抓 PixiJS/Cocos canvas 內的元素——這是架構限制，不是版本問題
-
Playwright codegen 對 Canvas 內點擊只會錄成座標點擊，極難維護
最佳實踐¶
-
Canvas 測試策略：用 network request intercept 驗證 API 呼叫，用截圖 diff 驗證視覺回歸
-
對 Canvas 遊戲做 E2E 測試時，把商業邏輯測試放後端（RPC level），前端只做 smoke test
相關概念¶
- Playwright CLI Property Scraping
- Qwen3 SLM Novel Generation
- ui-translator E2E Three-Layer Integration Testing
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-04-13 | 38030a5c-54da-4873-9a63-680709c843f1 | 本 session 釐清了 Playwright 對 Canvas 渲染框架（PixiJS）的根本限制，以及 Playwright CLI vs 一般 Playwright API 的差異，並調研了 Cocos TypeScript 引擎作為替代方案的可行性。 |