單元測試核心思想：測試先行、頻繁測試與自動化測試

為什麼需要單元測試？

產品出廠必經檢驗，業務類別亦同——唯有經過測試驗證，才能保證 API 正確性，避免 Bug 蔓延。業務功能測試屬測試人員職責，但 API 正確性必須由開發者負責。

傳統開發常見窘境：通宵除錯，最終發現問題極簡單。主因有二：

1. 增量式測試策略：先寫功能碼，模組完成才補測試。層層調用形成複雜網絡，Bug 一現需逐一排查，極度耗時。
2. 錯誤測試方法：各類別寫 main() 自測，需單獨執行、人工觀察。類別數增長時，舊測試易失效、覆蓋率難控。

現代測試三大核心思想

1. 測試先行

未寫實作前先寫測試，聽似不可思議，實則強迫開發者站在「呼叫者角度」設計介面，深入理解類別外在關係，介面更易用、結構更合理。實作細節留待編碼時處理。

2. 頻繁測試

測試非階段性工作，應貫穿編碼全程。類別間關聯緊密，功能調整常牽一髮動全身。頻繁測試可及早發現回歸錯誤，修復成本隨時間指數增長。這也是 XP (Extreme Programming) 核心實踐之一。

3. 自動化測試

非指「自動找出 Bug 的神奇工具」，而是：

• 為每個業務類別編寫獨立測試用例，程式碼調整時同步更新測試。
• 多個測試用例組成測試套件批次執行，如強力「Bug 嗅探器」，一旦失敗即輸出詳細錯誤報告。
• 測試規則由開發者定制，框架提供規範化編寫/執行機制，「靈敏度」取決於測試規則品質。

實踐建議

初期會觸動「慣性定律」產生阻力，似乎增加工作量。但隨專案規模擴大，傳統方法將捉襟見肘，而基於框架的測試技術依能「談笑自如」。請保持懷疑精神，親身實踐體會其帶來的長期效益與開發信心。