第 9 章 單元測試
本章介紹一些保持軟件邊界整潔的實踐手段和技巧。
9.1 TDD 三定律
TDD 要求我們在編寫生產代碼前先編寫單元測試。
三定律：
定律一 在編寫不能通過的單元測試前，不可編寫生產代碼。
定律二 只可編寫剛好無法通過的單元測試，不能編譯也算不通過。
定律三 只可編寫剛好足以通過當前失敗測試的生產代碼。
9.2 保持測試整潔
測試代碼和生產代碼一樣重要。髒測試會讓測試越變越糟，維護代價增大。故測試代碼和生產代碼一樣重要。
測試帶來一切好處
覆蓋了生產代碼的自動化單元測試程序組能儘可能地保持設計和架構的整潔。測試代碼了一切好處，因爲測試使改動變得可能。有了覆蓋率高的測試，可以毫無顧慮地改進架構和設計。
9.3 整潔的測試
整潔的測試有什麼要素？有三個要素：可讀性，可讀性和可讀性。在單元測試中，可讀性甚至比在生產代碼中還重要。測試如何才能做到可讀？和其他代碼中一樣：明確，簡潔，還有足夠的表達力。在測試中，你要儘可能少的文字表達大量內容。
9.3.1 面向特定領域的測試語言
不直接使用程序員用來對系統進行操作的 API，而是打造了一套包括這些 API 的函數的工具代碼，這樣就能更方便地編寫測試，寫出來的測試也更便於測試。
面向特定領域（我理解爲測試）的語言的技巧是：測試代碼呈現構造-操作-檢驗（BUILD-OPERATE-CHECK）模式。每個測試都清晰地拆分爲三個環節。第一個環節構造測試數據，第二環節操作測試數據，第三部分檢驗操作是否得到強的結果。
9.3.2 雙重標準
測試 API 中的代碼與生產代碼相比，的確有一套不同的工程標準。測試代碼應當簡單、精悍、足具表達力，但它該和生產代碼一般有效。畢竟它是在測試環境而非生產環境中運行，這兩種環境有着截然不同的需求。
有些事你大概永遠不會在生產環境中做，而在測試環境中做卻完全沒有問題。通常這關乎內存或 CPU 效率（在生產環境不會做，但在測試環境中做卻沒有問題，因爲不會影響測試環境的整潔）的問題，不過卻永遠不會與整潔有關。
9.4 每個測試一個斷言
單個斷言是個好準則，但是當一個以上斷言的前提條件相同，非要遵守單個斷言的準則，就會有重讀的代碼，所以單個測試中的斷言數量應該最小化。
每個測試一個概念
每個測試函數中只測試一個概念。
最佳規則是儘可能減少每個概念的斷言數量，每個測試函數只測試一個概念。
9.5 F.I.R.S.T.
整潔的測試還遵循以下 5 條規則：
快速（Fast） 測試應該夠快。測試應該能快速運行。測試運行緩慢，你就不會想要頻繁地運行它。如果你不頻繁運行測試，就不能儘早發現問題，也無法輕易修正，從而也不能輕而易舉地清理代碼。最終，代碼就會腐壞。
獨立（Independent） 測試應該相互獨立。某個測試不應爲下一個測試設定條件。你應該可以獨立運行每個測試，及以任何順序運行測試。當測試互相依賴時，頭一個沒通過就會導致一連串的測試失敗，使問題診斷變得困難，隱藏了下級錯誤。
可重複（Repeatable） 測試應當可在任何環境中重複通過。你應該能夠在生產環境、質檢環境中運行測試，也能夠在無網絡的列車上用筆記本電腦運行測試。如果測試不能在任何環境中重複，你就總會有個解釋其失敗的藉口。當環境條件不具備時，你就會無法運行測試。
自足驗證（Self-Validating） 測試應該由布爾值輸出。無論是通過或失敗，你不應該查看日誌文件來確定測試是否通過。你不應該手工對比兩個不同文本文件來確認測試是否通過。如果測試不能自足驗證，對失敗的判斷就會變得依賴主觀，而運行測試也需要更長的手工操作時間。
及時（Timely） 測試應及時編寫。單元測試應該恰好在使其通過的生產代碼之前編寫。如果在編寫生產代碼之後編寫測試，你就會發現生產代碼難以測試。你可能會認爲某些生產代碼本身難以測試。你可能不會去設計可測試的代碼。
9.6 小結
測試保證和增強了生產代碼的可擴展性、可維護性和可複用性。保持測試的整潔，讓測試具有表達力並短小精悍。