測試金字塔是 2009 年 Mike Cohn 提出的——底部大量 unit test，中間少量 integration test，頂部極少 E2E test。這個模型在當時解決了一個真實問題：E2E test 太慢、太脆弱，CI 跑 20 分鐘全是 UI automation，一改 DOM 就全紅。
2020 年，Kent C. Dodds 提出測試獎盃（Testing Trophy）。他的觀察是：現代前端應用的 unit test 覆蓋率很高，但 bug 大多發生在「元件之間的整合點」，不是在單個函式裡。獎盃的重心在整合測試。
兩個模型都沒錯，但它們描述的是不同的問題。
金字塔的邏輯
金字塔的核心假設是：測試越接近底層，越快、越穩、越便宜。
Unit test 測單一函式，毫秒級，無外部依賴，1000 個測試幾秒跑完。E2E test 起真實瀏覽器、打真實 API、等 DB 回應，一個測試幾十秒。同樣的信心，用便宜的測試買，不要用貴的測試買。
這個邏輯在後端業務邏輯複雜的系統裡很有效——訂單計算、優惠規則、權限判斷，這些邏輯有清楚的 input/output，unit test 直接測 domain function 最有效率。
金字塔撞牆的地方：當系統的 bug 主要來自整合點而不是 pure function 時，大量 unit test 會給你假安全感——每個 function 都對，但串在一起就壞了。
獎盃的邏輯
Kent C. Dodds 觀察到現代前端（React / Vue）的情況：元件本身很薄，邏輯在 hook 和 service 裡，真正的 bug 發生在「用戶點按鈕之後，資料有沒有正確顯示」這種跨邊界的行為。
獎盃把整合測試放在主力位置——不是測「這個函式回傳什麼」，而是測「這個功能的行為是否符合用戶預期」。用 React Testing Library 渲染整個元件樹，模擬用戶點擊，驗證畫面狀態——這比 mock 每個 prop 更接近真實使用場景。
╱E2E╲ ← 少量
╱─────────╲
╱ Integration ╲ ← 主力（獎盃最寬的地方）
╱─────────────────╲
╱ Unit Tests ╲ ← 適量
╱───────────────────────╲
╱ Static Analysis ╲ ← 底座（TypeScript / ESLint）
╲─────────────────────────────╱
兩個模型的選擇框架
不是「金字塔 vs 獎盃」的選邊站，而是系統的 bug 在哪裡，測試的重心就在哪裡：
業務邏輯複雜的後端系統（訂單、金融、權限）：bug 在 pure function 裡，unit test 直接、快速、精準。金字塔的重心合理。
前端元件 + API 整合的 web 應用：bug 在元件組合和 API 串接上，整合測試比 unit test 更能抓到真正的問題。獎盃的重心合理。
微服務之間的 contract：unit test 和 E2E 都抓不到跨服務的協議破壞，需要 contract test（Pact）——這兩個模型都沒有明確講這個層次。
實務建議：把測試分成三個問題個別回答——domain logic 怎麼測（unit test）、整合點怎麼測（integration test）、關鍵流程怎麼驗（E2E）。形狀是結果，不是設計起點。