整潔代碼之道 9 單元測試

測試是簡單的驅動式程序，讓我們能夠手工與自己編寫的程序交互

9.1 TDD 三定律

1. 在編寫不能通過的單元測試前，不可編寫生產代碼
   • 從測試的角度考慮代碼實現
2. 只可編寫剛好無法通過的單元測試，不能編譯也算不通過
3. 只可編寫剛好足以通過當前失敗測試的生產代碼

9.2 保持測試整潔

1. 測試必須隨生產代碼的演進而修改
2. 測試代碼和生產代碼一樣重要
3. 單元測試讓代碼可擴展、可維護、可複用

9.3 整潔的測試

1. 在單元測試中，代碼的可讀性非常重要
2. 比較好的單元測試應該呈現出 構造-操作-校驗（ BUILD-OPERATE-CHECK ） 的模式

9.3.1 面向特定領域的測試語言

1. 守規矩的開發者會將他們的測試代碼重構爲更簡潔和具有表達力的形式

9.3.2 雙重標準

1. 測試 API 中的代碼和生產代碼相比，存在不同的衡量標準
2. 測試代碼應該簡單、精悍、具有表達力，同時和生產代碼一樣有效
3. 測試代碼只需要在測試環境中運行，和生產環境存在本質的區別
4. 所以可以爲特定場景編寫一些特定代碼以滿足測試條件

9.4 每個測試一個斷言

1. 每個測試最後都需要有一個可快速方便理解的結論
2. 每個測試都只能有一個斷言，未免顯得過於絕對，應該是每個測試的斷言數量都應該最小化
3. 或者說每個測試都應該只測試一個概念
4. 最終結論：每個測試都應該儘可能減少斷言數量，同時一個測試只允許測試一個概念

9.5 F.I.R.S.T

1. 快速（ Fast ） ，測試應該夠快
2. 獨立（ Independent ） ，測試應該相互獨立
3. 可重複（ Repeatable ） ，測試應該可以再任何環境中重複通過
4. 自足驗證（ Self-Validation ） ，測試應該有布爾值的輸出
5. 及時（ Timely ） ，測試應及時編寫

9.6 小結

1. 對於項目的健康程度，測試和生產代碼一樣重要
2. 測試的存在，保證和增強了生產代碼的可擴展性、可維護性和可複用性