Playwright API 測試：強大的 request API，以及它的極限

Playwright API 測試做對了什麼

• 一流的 request context。 API 呼叫不需要瀏覽器頁面，因此檢查能以一次請求的速度跑完。

• 可重複使用的已驗證狀態。 登入一次、把狀態存下來，之後所有測試共用。這是相較於舊有框架最實際的一項改進。

• 兩個層級共用同一個執行器。 一套報告工具、一個 CI job、一種執行方式。當你就是那個要維護的人時，這件事的價值常被低估。

對於本來就長期使用 Playwright、而 API 覆蓋需求又只是中等規模的團隊來說，這確實是個相當不錯的位置。

它幫不上忙的地方

這些都不是框架的缺陷。它們是 API 測試中沒有任何執行器能替你解決的部分，同時也構成了長期成本的大宗。

覆蓋範圍取決於你想得到什麼

比較少被提起的問題是：手寫的測試套件只會涵蓋有人記得的端點。錯誤碼、邊界值與少用的參數，正好就是會出問題的那些情況，也正好是晚上十一點沒人會想動手寫的那些。

改由規格文件、或對執行中的服務做一次探索來產生覆蓋，會徹底改變你所涵蓋的範圍樣貌，而這比任何單一斷言寫起來順不順手都更重要。

專門打造的那一層負責什麼

不論你用哪套工具，決定一個 API 測試套件能不能撐過第一年的都是四件事：會過期的 session、只在執行期才存在的值、彼此相依的呼叫，以及沒人清理的資料。TestSprite 把它們分別稱為 Auto-Authentication、Dynamic Variables、Dependency Chains 與 Auto-Cleanup，而 API 測試文件 說明了背後的運作機制。

storage state 撐不住的地方

重複使用已驗證的 storage state，是 Playwright 在 API 工作上帶來最大的便利，而在你把整套測試建立在它之上以前，有三個邊界值得先弄清楚。

存下來的狀態是一個快照，因此只要 token 效期夠短，就會在執行到一半時過期，產生看起來和授權錯誤一模一樣的失敗。存下來的狀態也只屬於單一使用者，所以任何需要第二個帳號來驗證權限的測試，都得另外自行準備。而存下來的狀態還記錄了它產生時所對應的環境，這表示拿本機產生的狀態檔去跑 staging，會製造出一類讓人摸不著頭緒的失敗。

這些都不是不該用它的理由。它們只是解釋了為什麼專案最後都會長出一個小模組，用來依使用者、依環境管理狀態檔——而那正是你開始動手打造你原本想避開的那個東西的時刻。

讓兩者並行運作

瀏覽器流程，以及那些真的需要在同一個測試裡同時涵蓋兩端的跨層檢查，留給 Playwright。API 表面的廣度覆蓋，則交給自動產生的測試。兩者從同一條 pipeline 執行，彼此不需要知道對方的存在。

• GitHub App 是你在 TestSprite 儀表板中設定的一個 webhook。它會監聽你的 pipeline 本來就會發出的部署事件，因此你的儲存庫完全不用改動。

• GitHub Actions 則是把這個步驟放進你自己的 workflow，從終端機完成設定。最新的指令列在 CLI 儲存庫。

TestSprite 從哪裡接手

瀏覽器流程與跨層測試留給 Playwright。TestSprite 接手的是廣度與狀態處理——不論 request context 做得多好，這兩塊永遠還是你自己的事。

具體來說，就是用 Auto-Authentication 取代你得依使用者、依環境維護的 storage state 模組，用 Dependency Chains 取代 fixture 與執行順序慣例，並用綁定每一次執行的 Auto-Cleanup 取代那種必須在平行執行下保證安全的前綴比對刪除。覆蓋範圍來自你的規格與執行中的服務，而不是來自某個人記得要寫的部分。

結果是，那半天寫出來的輔助程式碼，不必再變成某個人長期背在身上的責任——真正的成本從來就不是寫的那一次，而是後續的維護。