Cypress API 測試真正擅長的部分
測試前置與清理。 透過 API 建立 UI 測試所需的狀態，而不是一路點過五個畫面。更快、更穩定，也是這項能力的正確用法。
跨層驗證。 在介面上執行某個操作，接著確認後端有正確記錄下來。這是實際存在的一類測試，而 Cypress 處理得很俐落。
少量的端點檢查。 當 API 的範圍還小，把它們留在同一套測試裡，是為了簡單而做的合理取捨。
規模變大後浮現的四個問題
工作階段有效期限
權杖在測試跑到一半時過期，失敗看起來卻像是產品本身的錯誤。
更新權杖的邏輯最後只能手工寫在 support 檔案裡。
呼叫之間傳遞的值
建立資源時拿到的識別碼必須傳到刪除的那次呼叫，而 Cypress 的指令鏈結在跨測試時會讓這件事變得彆扭。
於是大家把值寫死，整套測試就只能跑成功一次。
執行順序
真實的 API 涵蓋範圍是一張圖，測試檔案卻是一份清單。用手把這張圖編碼成順序，維護成本就是花在這裡。
第四個是資料清理。紀錄不斷累積，唯一性限制開始被觸發，分頁相關的驗證也會隨著資料變多而失準。
為什麼這些其實不是 Cypress 的問題
Cypress 是圍繞著瀏覽器驅動的測試生命週期設計的。上面每一項談的，都是存在於單一測試之外、甚至單次執行之外的狀態。你確實可以全部在 support 檔案裡解決，但解法會長成一套小型框架，而且得有人維護——這正是沒有人事先算進去的成本。
專為 API 打造的測試層改為承擔哪些事
不論你用哪一種工具，決定一套 API 測試能不能撐過第一年的，都是這四件事：會過期的工作階段、只在執行期間才存在的值、彼此有相依關係的呼叫，以及沒有人清理的紀錄。TestSprite 把它們分別稱為 Auto-Authentication、Dynamic Variables、Dependency Chains 與 Auto-Cleanup，而 API 測試文件 則說明了運作機制。
support 檔案是在哪一刻變成框架的
放在 Cypress 裡的 API 測試，有一個看得出來的臨界點：它不再只是幾個請求，而變成了基礎設施。這個點值得明確指出來，這樣你才能刻意做決定，而不是一路隨波逐流。
一開始只是在 support 檔案裡放一個登入指令。接著加上權杖快取，因為每個測試都重登一次太慢。然後是更新邏輯，因為快取會在執行途中失效。再來是一個把建立出來的識別碼存起來的輔助函式，好讓後面的測試找得到；接著是用檔名來約定執行順序；最後是一個在整套測試跑完後執行、而且必須知道上述所有細節的清理工作。
這些步驟沒有一個是錯的，每一步都是當下最理所當然的下一步。結果是一套幾百行的框架住在 support 目錄裡，只有一個人真正看得懂，而且它其實落在當初賴以建立的執行器之外。把這條軌跡描述出來的全部價值，就在於讓你及早認出它。
值得採用的分工方式
把 cy.request 留給測試前置、清理，以及那些真的需要在同一個測試裡同時涵蓋兩端的跨層驗證。把獨立的端點與整合測試涵蓋範圍，移到一個把那四個問題視為自己份內工作、而不是丟給你當作業的測試層。
兩套測試不需要知道彼此的存在，而且都可以在同一套流程中執行。
觸發的時機比機制更重要。把它掛在你的部署事件上，代表每一次變更都會被檢查，而不必有人特地決定要跑； GitHub App 可以從儀表板做到這件事，而一個 GitHub Actions 步驟則是在你的工作流程內部完成。細節請見 CLI 儲存庫。
你不再需要維護的東西
上面描述的那套 support 檔案框架，正是 TestSprite 要取代的東西。Auto-Authentication 負責處理工作階段的有效期限。Dynamic Variables 把識別碼從建立的呼叫帶到刪除的呼叫。Dependency Chains 會根據每個案例需要什麼、產生什麼，推導出一個安全的執行順序。Auto-Cleanup 只移除這次執行所建立的資料，而這正是平行執行能夠安全進行的原因。
測試涵蓋範圍也不再取決於誰剛好有空。測試計畫是從規格、或是對執行中服務做一次探索後產生的，其中包含那些永遠不會有人手動寫出來的錯誤路徑與邊界值，之後再用自然語言微調。
Cypress 保留它擅長的部分：測試前置、清理，以及那些真的需要瀏覽器與 API 同時出現在一個測試裡的跨層檢查。兩者在同一套流程中執行，彼此互不需要知道對方的存在。
cy.request 是不好的做法嗎？
完全不是。用在測試前置和跨層檢查上，它就是對的工具。它的限制在於規模，而不是對錯。
我們可以把全部都留在 Cypress 裡嗎？
可以，但你最後會親自維護工作階段處理、值的擷取、執行順序與資料清理。範圍小的時候值得，超過之後就很貴。
那 Cypress 的元件測試呢？
完全不受影響。元件測試回答的是另一個問題，維持現狀就是最好的選擇。
要怎麼避免重複的測試涵蓋？
用問題來切分。Cypress 回答的是使用者看得到的流程能不能走通，API 測試層回答的是端點的行為是否正確。如果一個測試放在兩邊都會通過，那它就該放在成本比較低的那一邊。
API 測試層需要我們的原始碼嗎？
不需要。它是對著執行中的服務進行測試，透過規格或一次探索來得知有哪些東西存在。