「這些到底要寫到什麼時候……」光是完成一個功能就已經很趕了，還被要求寫測試程式碼，老實說只會先嘆氣。
先說結論，寫測試程式碼的真正理由是「保護未來的自己」。現在多花10分鐘，是為了避免3個月後在凌晨爆發的服務中斷。
為什麼要寫測試程式碼？
最大的理由是，修改程式碼不再令人害怕。
程式碼不是寫完一次就結束了。你會持續修改並加入功能。
沒有測試時，每修改一行程式碼都會感到不安。「改了這裡，其他地方不會壞掉嗎？」
有測試的話，修改後執行一次就能確認。綠燈代表安心，紅燈則能立刻看出哪裡壞了。
這稱為「回歸測試」，也就是找出原本正常、後來又壞掉的部分。
即使麻煩也要寫的真正理由
老實說，測試程式碼一開始會讓人覺得是在吃虧。畢竟它不會增加看得見的功能。
但專案越大，情況就越不同。
功能增加到30個、50個後，不可能靠手動逐一確認。每修改一處，也不可能把所有地方都點一遍。
這時有了測試，只要一行指令，就能在幾秒內驗證數十個案例。
第二個理由是，測試程式碼本身就會成為「文件」。
看過寫得好的測試程式碼，就能一眼看出這個函式對哪些輸入會產生什麼結果。
註解過時後可能會說謊，但測試會被執行，因此無法說謊。
來看個簡單的例子：計算折扣金額的函式測試。
// 11萬元 10% 折扣 → 9應為1千元
@Test func 套用_10折扣_百分比() {
let result = applyDiscount(10000, rate: 0.1)
#expect(result == 9000)
}光看這個測試，就能立刻理解applyDiscount這個函式的用途。
測試程式碼該如何開始？
一開始就想測試所有東西，很快就會筋疲力盡而放棄。
我建議這樣開始。
- 先從金額計算、登入等「出問題就不得了」的核心邏輯開始
- 條件分支很多、容易搞混的函式
- 曾經發生過錯誤的地方（用於防止復發）
相反地，單純的畫面程式碼或經常變動的部分可以之後再做。
目標不是把所有內容都測試到100%，重點是衡量成本與效益。
常見問題
Q. 寫測試會讓開發變慢嗎？
A. 一開始會變慢。但從專案中期開始反而會更快，因為尋找並修正錯誤的時間會大幅縮短。
Q. 測試涵蓋率多少才好？
A. 不必執著於數字。70～80%就足夠，更重要的是重要邏輯是否都有涵蓋。
測試程式碼不是炫耀實力，而是為未來的自己與同事準備的安全裝置。
現在就替今天寫的一個函式加上一個測試吧。感受過那盞小小綠燈帶來的安心後，就會親身明白為什麼大家都叫你寫測試。