代碼整潔之道-第9章-單元測試-讀書筆記

第 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 小結

　　測試保證和增強了生産代碼的可擴充性、可維護性和可複用性。保持測試的整潔，讓測試具有表達力并短小精悍。

9.7 文獻