測試自動化框架實際上包含哪些東西
工作階段與憑證
依環境取得、快取並更新 token，而且要能在多個平行執行的 worker 之間安全運作。
測試資料
為每個測試建立它需要的資料、加以隔離，並在結束後精準地只清掉這些資料。
執行順序與相依關係
知道什麼必須在什麼之前執行，並且略過相依的測試，而不是讓它們被判定失敗。
再加上真的會有人看的報表、環境設定、重試策略，以及一套能把不穩定的測試隔離起來、又不會讓它就此消失的做法。測試本身通常才是其中最小的一塊。
隱藏成本
這些零件全都出自當初建置框架的那個人之手，寫法也只有那個人完全理解。等到那個人離開，框架就變成團隊不敢動的東西；而一套沒人敢動的測試，最後只會被隔離擱置，而不是被修好。
什麼時候該自己打造
需求特殊。 有現成工具都無法處理的協定、平台或法規遵循限制。
測試是產品的核心。 如果你賣的就是可靠度，自己掌握這套測試骨架可能具有策略意義。
你有能持續投入的人力。 不是一個人投入一季，而是有人維護好幾年。
什麼時候不該
如果誠實的理由是團隊喜歡做工具，或是評估之後沒有明確結論，那這個框架會先被做出來，然後慢慢被丟在一旁。這才是常見的情況，值得在第一次 commit 之前就先把話講清楚。
框架已經變成產品的徵兆
值得先記下幾個具體訊號，因為這個轉變是漸進的，也不會有人特地宣布。
有人問怎麼新增一個測試，而答案要花超過兩分鐘才講得完。新成員寫第一個測試的方式，是複製現有的測試再改幾個值，並不理解底下的 fixture 在做什麼。測試失敗時，隨之而來的問題是框架是不是改了。有一個檔案沒有人想碰。框架本身的工作固定以獨立項目出現在 sprint 規劃裡。
只要符合其中任兩項，你手上就有一個內部客戶只有一個團隊的產品。這本身不見得是錯的，很多組織就是刻意這樣選。真正的問題在於，它是在沒有任何人做出選擇的情況下發生的，而這正是多數的情況。
折衷路線
你刻意指定的那些案例，繼續用手寫測試；廣度則交給自動產生的覆蓋範圍，而工作階段、資料、執行順序與清理這些問題，由產品本身解決，而不是變成你的基礎設施。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，同樣的設定在 TestSprite 儀表板裡也做得到。其餘的 CLI 功能都在 CLI 儲存庫。
如果這條 pipeline 屬於另一個團隊， GitHub App 就是阻力最小的做法：它是一個 webhook，不會動到你儲存庫裡的任何東西，並且在你的建置回報新版本上線時觸發。如果你希望檢查結果直接顯示在儲存庫裡，也可以用一個 GitHub Actions 步驟來達成。
不自己打造的話，你會得到什麼
那些原本會變成你自家基礎設施的部分，直接以產品的形式提供。Auto-Authentication 讓工作階段在整趟執行中保持有效，Dynamic Variables 在呼叫之間傳遞值，Dependency Chains 推導出執行順序，Auto-Cleanup 則精準清除這趟執行所建立的東西。報表、環境設定與重試行為也一併附帶，所以不會有任何一塊變成沒人想碰的檔案。
測試覆蓋範圍由你的產品產生，再用白話語言微調，這就省掉了另外一半的成本：每一個測試都得由某個時間被各方搶著要的人親手寫出來。
重點不是自己打造就是錯的。而是多數團隊從來沒有真正決定要打造，卻在第九個月發現自己手上多了一個只有一位內部客戶的產品。保留你刻意指定的那些測試，讓測試骨架變成別人的問題，這個版本的做法不會累積出一個你從未編列預算的維護者。
打造一套框架要花多久？
第一個能動的版本，幾週。能處理工作階段更新、平行安全的資料與可讀報表的版本，幾個季度。
最常被低估的是哪一塊？
測試資料。要在平行執行下安全地建立、隔離並清除它，比其他所有事情加起來都難。
我們應該用現成的框架嗎？
幾乎永遠都該。在現成框架上開發，和自己做一套框架是兩回事，而後者往往是悄悄發生的那一種。
怎麼知道我們這套已經變成負擔？
當大家開始繞過它，或是只剩一個人改得動它的時候。這兩個都是很晚才出現的訊號，而且都很常見。
之後還能遷移出去嗎？
測試很少能直接搬走。請假設這筆投入是沉沒成本，並據此做決定。