從 testcafe 遷到 playwright 你需要注意什麼？

作者：楊若｜QE_LAB

從 testcafe 遷到 playwright 你需要注意什麼？

本篇部落格主要記錄專案 UI 自動化從 testcafe 到 playwright 的遷移過程，標題黨了一點，但希望可以給點進來的大家一點點的收穫。

1. 為什麼要從 testcafe 遷到 playwright

最主要的原因是專案 UI 版本庫進行了大升級，幾乎所有元素，佈局都發生了一些變化，比起每個元素定位比對，debug，可能直接寫一版耗費的精力還要小一些。

其次，是使用 testcafe 時元素定位不穩定，目前專案使用 document.querySelector 來維持，但是如果涉及到了該元素相關互動的 debug 或者修改，會更加複雜。

最後一點是對 playwright 的 test generator 的好奇。
這項工具需要在 VS code 中安裝 playwright 的外掛

安裝後可以直接點選 record new，playwright 會開啟瀏覽器，並將你在瀏覽器上的操作，直接記錄成測試程式碼。並且它支援三種斷言 “assert visibility”，“assert text”，“assert value”。這就相當於任務繁重的定位元素以及步驟的程式碼都可以透過直觀的頁面上操作就完成了。
詳情可見 playwright 文件

2. 遷移過程中發生了什麼

1. 我首先用 playwright 的 test generator 的 record new 功能把測試用例在 Chromium 瀏覽器上都走了一遍，playwright 將所有的元素和步驟自動記錄成程式碼，類似下圖
2. 這個時候的程式碼會有一些不必要的步驟，比如上圖的 6，是我們先點選到元素再進行輸入。在測試用例裡就可以刪掉點選的不止，直接輸入文字。大致篩過一遍程式碼，刪掉類似的操作後，再按照 POM 將操作，頁面和斷言拆到不同的測試檔案，頁面檔案和測試用例中。
3. 接下來，就是看 playwright 文件來配置 playwright.config.ts 檔案，比如測試報告形式，瀏覽器等等。在這個時候我發現 playwright 不像 testcafe 可以整體配置在測試失敗時自動截圖。那麼我最後解決這個問題的辦法，是在每個測試檔案中加入一段 afterEach 的程式碼。但是我覺得這不應該是個值得提倡的實踐，如果大家有更好的解決辦法，也歡迎評論區給我講講🙏 est.afterEach(async ({ page }, testInfo) => { if (testInfo.status === 'timedOut') { const screenshotPath = ./screenshots/${testInfo.title}.png; await page.screenshot({ path: screenshotPath , fullPage: true }); console.log(Screenshot saved: ${screenshotPath}); } });
4. 配置後，就是完整的執行每個測試檔案了。 這個時候需要注意，playwright 預設的配置是並行執行每個測試檔案，在同一個檔案中順序執行測試用例的。如果涉及到測試資料的重複或者用例執行先後順序的問題，就需要提前在 playwright.conf.js 中將 “fullyParallel” 這個引數從 true 改到 false。除此之外，在完整跑過一遍用例時，還要注意有一些元素的定位可能是用了動態的引數，需要手動再定位一下，確定所有測試用例穩定透過。
5. 最後配置流水線的 yaml 檔案，上流水線測試。 在這一步中，我遇到了 playwright 報錯沒有安裝瀏覽器。手動新增了 npx playwright install 的命令在流水線上執行安裝後，就可以正常執行了。

3. 總結

至此 UI 自動化測試就算完整遷移結束了。
總結一下，遷移過程中需要注意不同的測試框架配置上的差別，在配置檔案這一塊，直接看文件比 chatgpt debug 還是要節省不少時間的。
playwright 的 test generator 也是個非常便利的工具，大大節省了複雜元素定位的精力，如果大家有更深度的使用實踐的話，也歡迎和我一起討論呢～