如果去過暢飲吧和單點吧，應該就會了解單點為什麼比較貴了 (?)，暢飲吧就是給你便宜買醉用的，所是材料加進去喇一喇就出杯了，反正都是照著經典調酒的酒譜調的，大方向不會跑掉。

單點吧除了維持味道的大方向，也會加入調酒師個人的想法，例如挑選材料的品牌、調整融水技法、加入特別的佐料等，經過不斷測試才調校出調酒師的風格！

前面一直沒有去細看測試案例是怎麼設計的內容，儘管功能操作都還算正常，但也是時候來面對真正的問題啦。

分析現況

先換個模型來分析看看：

切 Claude 分析之後，會發現列出來的問題，其實也是我覺得一開始學測試時常犯的：

過於注重「測試金字塔」的教條，變成形式主義，該測的東西沒有測到。

當然我們不能留下一句「我覺得你這樣測不對」就開溜了 XD

不然這篇文章沒辦法灌水到 300 字啊！

什麼是該測的

這個問題的答案就在使用者故事！

即使後來專案改動、變大、翻新等等，這些規格文件都會訂出每個功能的優先度，沒訂的話還是快逃吧。

功能的重要程度通常是根據利害關係人的期望排出來的，簡言之就是「賺錢的地方」先測。

如電商網站的最重要的，就是讓「買東西」這件事可以成立！

所以買東西就可以拆解出：

• 端對端測試 (E2E Test)：加入購物車到結帳完成的完整流程
• 整合測試 (Integration Test)：商品進入到購物車、結帳到金流支付等等的部分連動流程
• 單元測試 (Unit Test)：訂單金額計算的邏輯

所以測試金字塔並不是不對或不重要，而是特定情境下的測試策略，像 ERP 系統、交易系統或是有演算法、複雜流程判斷等，就需要從單元測試開始做，保證這些計算邏輯的正確性。

不過以上都是我個人淺見，測試的策略要根據專案的狀況調整，搞不好就是沒人想寫測試啊，那還是得乖乖接隕石（欸）！

後端

這個專案沒什麼太多計算功能，所以單元測試就是負責保護資料輸入輸出的邊界，例如不合法數值的判斷、通知流程的判斷、JWT 的簽發判斷。

service 應該就很好聯想了吧 XD 這些跟 DB 操作相關的部分大多都有整合測試，是不是能正確地整合業務邏輯並成功操作資料。

E2E 測試比較多是因為後端不像前端一樣需要開瀏覽器或模擬器，所以測起來還是蠻快的，而且 guard、pipe、cookie 這些 HTTP 前段的流程比較需要 e2e 來保護。

前端

跟 UI 細節有關的測試都移除了，一方面是 UI 細節只要有變動，就算功能正常，這些測試也會壞掉，而且這些東西都是肉眼可見（應該沒有人矇著眼開發 UI 吧），我覺得不太需要大量的單元測試來覆蓋。

所以前端的重點就落在整合測試了！使用者的操作基本上都是要測的，這次的修改大多都有覆蓋到。

因為還沒有裝 Playwright，所以暫時沒有前端 E2E 的部分 XD

Playwright 也提供 MCP 給 Agent 去接，我近期工作蠻常使用，算是非常強大的前端測試工具，蠻推薦大家使用！

小結

1. 在方向不對的測試保護下，持續擴大專案規模會是一場災難
2. 從使用者故事、操作流程來拆解要制定什麼測試案例