依各層獨有價值繪製的測試工具地圖
單元測試
只有這層抓得到： 錯誤的邏輯，以毫秒為單位回饋，並精確指出失敗位置。
這是現存最便宜的回饋，沒有任何東西能取代它。
API 測試
只有這層抓得到： 服務邊界上的錯誤行為，包含任何介面都不會曝露出來的情況。
比驅動瀏覽器更快，也更精準。
端對端測試
只有這層抓得到： 每個零件都正常，組裝起來的產品卻壞掉。
最慢的一層，也是唯一能回答使用者疑問的一層。
環繞在這三層周圍的，是三種專門工具： 契約測試 用於獨立部署的服務之間的結構漂移， 負載測試 用於容量，以及 安全掃描 用於已知的弱點類型。每一種都能抓出三個主要層級抓不到的東西，但也都無法取代那三層。
缺口通常在哪裡
多數團隊有單元測試，也有一些端對端覆蓋，中間那層卻很薄。這是本末倒置，因為 API 層只需上層的一小部分成本，就能抓出大多數使用者看得見的缺陷。
第二個常見缺口，是測試覆蓋追不上程式碼的成長速度。這不是再多買一類工具就能解決的，而是要靠不受「有人能寫多少測試」限制的覆蓋來解決。
比功能比較表更有用的問題
不論你正在挑選哪一層的工具，都該問：對負責修復的人來說，一次失敗看起來是什麼樣子？以及，一次根本沒跑到斷言的執行，會不會被回報為通過？這兩個問題對工具價值的預測力，勝過比較頁上的任何內容。
你早就有、卻沒在用的工具
在添購任何東西之前，值得先盤點哪些工具已經裝好卻閒置著，因為多數組織擁有的測試能力，都比實際用到的還多。
通常會有一套單元測試框架，裡面躺著兩年前寫的幾個測試；經常還有一套每晚執行、卻沒人看的瀏覽器測試套件；也常有一個掃描工具，把報告送進一個已被靜音的頻道。這些工具當初都是有理由才導入或建置的，後來也都是有理由才被棄用，而在為同一類工具再花一次錢之前，這個理由值得先弄清楚。
常見的答案是：沒有人採取行動的產出，最後就會被忽略，而這是流程問題，不是工具問題。新工具會繼承同一套流程，最後走到同樣的下場，只是更晚、也更貴。
下一個小時該花在哪裡
那條壞掉會讓你很難堪的流程，做端對端覆蓋。
支撐它的 API，連同負面案例一起覆蓋。
上一次壞掉的東西，變成一道永久的檢查。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果不想在本機安裝，儀表板也涵蓋同樣的範圍；完整的指令集則收錄於 CLI 儲存庫。
GitHub App 是你在 TestSprite 儀表板中設定的 webhook。它會監聽你的管線本來就會產生的部署事件，因此你的儲存庫不需要有任何改動。
GitHub Actions 則是把這個步驟放進你自己的工作流程裡，從終端機完成設定。
TestSprite 在這張地圖上的位置
在 API 層與端對端層，而這兩層正是大多數使用者看得見的缺陷所在，也是常見缺口所在。它測試的是實際執行中的產品，而不是 mock；它會從你的原始碼與一輪探索產生測試覆蓋，並以白話語言細部調整。
Auto-Authentication 會在整個執行過程中維持工作階段有效，Dynamic Variables 讓數值在呼叫之間傳遞，Dependency Chains 會推導出執行順序，Auto-Cleanup 則只清除該次執行所建立的東西。瀏覽器步驟描述的是意圖而非選擇器，因此改版不會讓整套測試變紅。
單元測試仍然由你自己掌握，也仍然是你手上最便宜的回饋。契約測試、負載測試與安全掃描仍是各自獨立的工具。好處在於，中間那層薄弱的地帶被補上了，而且不會增加與出貨進度互相排擠的撰寫負擔。
我們該擁有多少測試工具？
能覆蓋你需要的層級就好，愈少愈好。每多一個工具，就多一樣要設定、要執行、要解讀的東西。
測試金字塔現在還適用嗎？
這個形狀是個合理的預設。真正有用的版本不是比例，而是去問每一層各自能抓出什麼別的層抓不到的問題。
我們應該在各團隊之間統一標準嗎？
在報告與 CI 整合上，應該。但把同一套工具硬塞給每個團隊，通常只會變成一個團隊用得很好、其他團隊避之唯恐不及。
最常見的缺口是什麼？
薄弱的 API 層。團隊從單元測試直接跳到端對端測試，錯過了那一層——在那裡，大多數使用者看得見的缺陷抓起來成本最低。
怎麼知道一個工具值得留下？
看它攔下了多少漏出去的缺陷，以及有沒有人真的在看它的產出。沒有人看的工具，只是一筆訂閱費。