playwright agent

🐢 簡單來說 playwright agent 幫你建立了 CI 流程、MCP 設定、客製 agent 完全透過對話一步一步的去作計劃→生成→修復

官方教學：https://playwright.dev/docs/test-agents

基本設定

使用指令將 Playwright 測試代理定義新增至專案 init-agents。每當 Playwright 更新以採用新的工具和指令時，這些定義都應重新產生。

以下會使用 VS Code，版本最低需求是 v1.105（2025 年 10 月 9 日發布）

指令：npx playwright init-agents --loop=vscode

建議在 vscode terminal 中輸入

指令輸入完畢會自動幫你生成以下檔案：

記得要把 server 啟動，如 npm run dev，依據官方文件有以下策略：

Step1. 計畫

使用規劃代理程式（Planner agent） Agent 會探索您的應用程序，並為一個或多個場景和使用者流程產生測試計劃。

之前有寫過這段測試流程因此直接說明流程

記得選剛剛的計畫通 agents

我想要制定列印網檔案上傳的流程測試
目前我們的測試方式是

到檔案上傳頁面，router path: `/ibonprinter`
點擊新增檔案按紐
上傳位於程式碼`/tests/test-data/`裡面的檔案
測試多種錯誤情境，如上傳八個檔案以上或如超過總大小15M以上
需點擊我已詳閱檔案上傳擊下載申請同意書不然按鈕無法點擊
點擊預選列印規格會出現規格選擇
點擊確認上傳如果上傳列表有非圖片會出現提示框
如果都僅有圖片會打API如果成功會有取件碼資訊(判斷有取件編號即算成功)

🐢 他會開始設定測試環境並探索「我舉例的功能」，這個過程中就是只有「確認權限他問我要不要這樣做」→ 我同意允許。 最後會給出一份完整的測試計畫

🐢 第一步驟的小感想

• 覺得他很厲害有查到我之前寫的檔案上傳測試 code：file-upload.spec.ts
• 另外他生成一個 /e2e/file-upload-comprehensive.plan.md，和官方文件 /specs 完全不一樣，他的建議是保持目前位置（e2e） 比較合適，原因：
  1. 專案一致性 - 你的專案已有 e2e 結構，且現有測試檔案 file-upload.spec.ts 就在此目錄
  2. 關聯性更強 - 測試計畫與實際測試程式碼放在同一層級，方便管理
  3. 不影響功能 - .plan.md 檔案純粹是文件，位置不影響任何工具執行

Step2. 生成

使用生成器代理程式（generator agent） Agent 使用 Markdown 計劃產生可執行的 Playwright 測試。它會在執行場景的同時即時驗證選擇器和斷言。Playwright 支援產生提示，並提供斷言目錄，以便進行高效的結構和行為驗證。

🐢 建議

執行前先確認 file-upload-comprehensive.plan.md 裡的「所有檔案位置」，因為他不一定會寫對的路徑目錄

如果一開始就錯會有點浪費時間和 token

1. 請他生成計畫的第一個測試

簡單粗暴的 Prompt，就是剛剛 md 的第一小節標題

# 執行所有檔案上傳測試
npx playwright test tests/e2e/uploadfile/

# 只執行基礎功能測試
npx playwright test tests/e2e/uploadfile/basic-functionality/

# 執行特定測試
npx playwright test tests/e2e/uploadfile/basic-functionality/page-accessibility.spec.ts

🐢 建議

先測試一下 npx playwright test tests/e2e/uploadfile/，因為他都粉飾太平覺得自己寫的都是對的 =___=

😫 執行失敗先確保伺服器正在運行如 npm run dev

如果習慣用 PowerShell 執行，建議改在 vscode terminal 執行指令，如 npx playwright test 和 npm run dev 都在 vscode terminal 執行

請另一個 tab 去跑 playwright test

2. 請他生成計畫的第二個測試

同樣簡單粗暴的 Prompt，就是剛剛 md 的第二小節標題

⏸️ 他很勤勞的指出要不要生成 Dropbox 整合測試，這邊我以前一直不想要用，和 agent 討論了一下我的立場，以下是他的反饋：

對於需要第三方登入的功能，我們採用了**「測試整合觸發，不測試實際登入」**的策略：

✅ 可以測試什麼：

• Dropbox 按鈕是否可點擊
• 授權對話框是否正確顯示
• 說明文字是否完整呈現
• 點擊後是否正確跳轉到 Dropbox 授權頁面

❌ 不需要測試什麼：

• 實際的 Dropbox 登入流程
• 檔案選取功能
• 授權成功後的回調處理

實際測試發現

測試過程中發現點擊「我知道了」後，系統會開啟新分頁導向 Dropbox OAuth 授權頁面，授權 URL 包含正確的 client_id 和 redirect_uri，原頁面的 Dropbox 按鈕保持可用狀態。

🐢 碰到了問題！！

依樣測試一下，他會把這幾項分在不同目錄中，因為我只想要針對剛剛生成的做測試， 可以下 npx playwright test tests/e2e/uploadfile/advanced-features/

但從這邊開始寫好的測試越來越容易失敗，但單隻測試執行都可以通過，猜測應該是後端被打掛了，導致回應變得非常慢

和 Agent 詢問如何把 timeout 時間變長，調整完 playwright.config.ts 的設定就沒問題了

actionTimeout: 10000,
navigationTimeout: 30000,

感覺他做了很多事但看了目前累積的 Context Window，卻比我想像的還要少，用量是 80.8k Tokens

• Day1
  • 用了 Context Window 的將近六成，和融資水位一樣
  • 盡量不要超過一半比較好，所以計劃明天清除這一個，在另開一個新的 session
  • 今天最後的總用量紀錄為 63.4%
• Day2
  • 最後的總用量紀錄為 74.7%

3. 請他生成計畫的第 3-5 個測試

同樣簡單粗暴的 Prompt，就是剛剛 md 的小節標題

🐢 碰到了問題！！

這次他沒有寫出測試，不確定是不是因為 session 清除導致他記憶喪失還是別的原因，因此我和 agent 確認：「所以目前測試已經涵蓋了嗎?」但他還是回答他寫好了，這時就需要檢查功課了，恩⋯ 的確在騙人喔 🙄

總之這一次新的 session 他沒有權限幫我寫（應該是因為上一個有允許，但這個新人 session 有點笨⋯）

如果有 session 快滿的話直接點「精簡交談」或是下 /compact 會好一點。

我想要制定列印網檔案上傳的流程測試
目前已經有這樣的流程

請你一句計劃來生成playwright code
並且我允許你直接寫出程式碼
如果沒有權限可以向我詢問

這樣才比較聰明一點，不過他其實也會把 code 寫在聊天室裡面，複製貼上到程式碼中也可以。另外如果像是檔案上傳這邊的測試檔案是放在目錄 /tests/test-data 中

|-tests
   |-test-data
   |-e2e
     |-uploadfile
            |-file-upload-comprehensive.plan.md  ## 測試計畫
            |-basic-functionality
              |-page-accessibility.spec.ts        ## 實際測試檔案

由於目錄結構如上，因此在程式碼中引用檔案的路徑會是 ../../../test-data/MB1.jpg

第三個 agent — playwright-test-healer

• 如果測試一直不過我會看一下測試代碼發生什麼事，但如果解的有點鬼打牆我就會讓這個 agent 幫忙
• 如果有 i18n 需求不應該把 aria-label 寫死成中文，建議在 data-testid 設定可識別的英數字

<b aria-label="取件編號" data-testid="pickupId">{{ props.pickupId }}</b>

小感想

整個流程非常順暢且簡單，用了一陣子覺得關鍵不是省多少時間而是多做了什麼，有些 case 之前根本就沒時間做，但 agent 預測了我的預測，把一些頭腦閃過想做但因為沒時間放棄的東西做完。

但 debug 時間並沒有覺得比較少，但有 agent 協作不至於會做不出來，讓人很有安全感～