前言
近期在回顧一些測試的概念，其中有個測試金字塔的概念來自於 Mike Cohn 的書 《Succeeding with Agile: Software Development Using Scrum》。還沒有看過這本書，但這個詞彙只要有研究過測試多少都會接觸到，這次來重新了解一下並輸出自己對這個議題的理解。
測試有三種
- 單元測試：測試程式碼最小功能單位的測試，如無依賴單一函式。
- 整合測試：測試模組之間是否運作正確，如 DB 和後端服務。
- 端到端測試：測試用戶實際操作流程。
單元測試驗證單一組件，整合測試檢查組件交互，端到端測試驗證整個系統。
測試要像金字塔
測試金字塔是一種概念關於測試理想上的最優分佈，強調從成本考量來看，透過大量能夠快速執行、撰寫、獨立的單元測試作為基底，隨著測試範圍的提昇成本也逐步升高，測試也會更為脆弱難以維持。範圍更廣的測試會因為任何一丁點錯誤而失敗，所以讓我們在問題的初期小範圍測試就快速抓出問題。
我體會的真實世界測試
有用的程式都是掙扎試錯過來的，現實世界需求不確定的情況下測試只會是絆腳石，所以大概也只有存活下來的程式才有需求去維護測試。最可能遇到的情境是程式趨向穩定但從來沒有自動化測試甚至文件，對代碼的信心度極低且有點改不動的狀況，遇到太多改 A 壞 B 或測試的負擔過大才會開始考慮測試。
要根據金字塔模型從單元測試開始補齊嗎？好像沒有必要…… 一是一時半會補不完，二是不符合效益，很多邏輯都是一次性且充滿取捨的。
反而這時候是最脆弱最難維護的 E2E 測試比較幫得上忙，因為它是黑箱測試（不需要知道內部程式邏輯），可以補上期望的行為即可，一次測試大量功能並提供程式能運作的信心。
測試金字塔是很好也有道理的的概念，但實際情境中沒有這麼美好。
世界在改變測試也是
測試的工具與環境還在持續演進，也有不同的概念可以解決問題，像是為什麼測試會是「慢」的？為什麼它會被視為「絆腳石」？
- 在 TDD 的概念中，要求測試（自動化文件）要先定義清楚才能寫下代碼，測試角色不一定是擋路的護欄而是指標，防止走錯路。
- 在 AI 有清晰上下文的協助下，測試是彈指就能補足的事。
- 測試工具和硬體的增強，測試可以執行得更快更即時。