AI 網頁開發測試該檢查的地方
| 步驟之間的狀態 | 表單送出了，後方的清單卻沒有重新整理。篩選條件一路殘留到根本用不上它的畫面。 |
| 時序 | 資料還沒回來就先渲染，或是元件已經消失之後，請求才回應。 |
| 第二個使用者 | 擁有權與可見性，都沿用了開發當下那個工作階段的假設。 |
這些問題都不會出現在 diff 裡，所以審查再快也幫不上忙。它們只要實際操作跑起來的應用程式三十秒就看得見，所以檢查必須在那裡進行。
為什麼代理程式自己寫的測試補不上這個迴圈
跟著實作一起產生的測試，會共用實作的假設。如果程式碼認定某個端點回傳的是空陣列而不是 404，測試就會用同一套認知去斷言，然後順利通過。你得到的是覆蓋率，而不是獨立的訊號。
能補上迴圈的檢查，必須以預期行為為準去實際操作已部署的產品，而不是以程式碼對自己的認知為準。
讓它快到真的會被用起來
驗證步驟如果比開發這個功能還花時間，就會被跳過，而且跳得有道理。有三件事能讓成本維持在合理比例：以流程而不是畫面為單位、把串接的步驟維持得短，以及在 pull request 上執行，而不是每次存檔都跑。
讓迴圈緊湊到真的用得下去
讓人覺得慢的驗證步驟就是會被跳過，而且跳過是理性的選擇，所以節奏和涵蓋範圍一樣重要。
有三件事能讓成本維持在合理比例。以流程而不是畫面為單位，因為一個流程是一項檢查，一個畫面卻是五項。把每條流程控制在仍然抓得到真正問題的最短路徑上，通常是三、四個步驟，而不是十個。並且把完整的測試套件放在 pull request 上跑，同時留一兩項檢查快到可以在開發過程中直接執行。
最後這個區分最常被忽略。開發過程中跑的檢查，和把關合併的檢查，任務並不相同；想用同一套測試同時應付兩者，結果不是慢到無法常跑，就是薄到不值得信任。
把它放進開發迴圈
安裝設定會把驗證技能裝進程式開發代理程式裡，讓檢查發生在工作進行的地方，而不是變成另一件額外的雜事。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想安裝任何東西，儀表板也能做到同樣的事。命令列能做的其他一切，都收錄在 CLI 儲存庫。
GitHub App 是你在 TestSprite 儀表板中設定的 webhook。它會監聽你的管線本來就會產生的部署事件，因此你的儲存庫完全不必改動。
GitHub Actions 則是把這個步驟放進你自己的工作流程裡，並從終端機完成設定。
TestSprite 能驗證、而代理程式做不到的事
已部署的應用程式，比對的是你說它應該有的行為，而不是程式碼自己的假設。重點就在這份獨立性：跟著實作一起寫出來的測試會共用實作的假設，所以它們會與實作一致，包括兩邊同時出錯的地方。
安裝設定會把驗證技能裝進你的程式開發代理程式，讓檢查成為修改過程的一部分。步驟寫的是意圖而不是選取器，失敗則會以一整包資訊回傳，讓代理程式可以直接據此行動，修正也因此能留在與修改同一個迴圈裡。
你得到的，是狀態、時序與第二個使用者這幾類問題在合併前就被抓到，而不是由使用者發現，而且驗證步驟不會比開發這個功能還久。
這會拖慢開發速度嗎？
比它省下的除錯時間少。要比較的對象不是零成本，而是在上線之後才發現同一個缺陷。
代理程式可以測試自己的成果嗎？
它可以執行檢查。但檢查本身必須來自預期行為，而不是來自實作，否則就等於自己改自己的作業。
那它產生的那些測試呢？
留著它們當覆蓋率用，但不要把它們當成獨立驗證。它們從產生方式上就注定會同意程式碼。
上線前要做到多少覆蓋率？
那些壞掉會讓你很難堪的流程，加上任何牽涉到金流或權限的部分。再從真實發生過的事故往外擴充。
這在本機開發時也能用嗎？
前端的測試執行可以透過通道連到你機器上的應用程式，所以在任何東西部署之前就能先做檢查。