今日分享：程式碼整潔之道- 單元測試

從開發的角度來講，先把變數、函數依照一定的命名、格式組織好，接下來，開始寫程式碼，在業界，很多提倡測試驅動開發，接著跟大家聊一下單元測試。

TDD是測試驅動開發（Test-Driven Development）的英文簡稱，是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。 TDD的原理是在開發功能程式碼之前，先編寫單元測試案例程式碼。

1、TDD三定律

定律一 在寫不能通過的單元測試前，不可寫生產程式碼。

定律二 只可寫剛好無法通過的單元測試，不能編譯也不算不通過。

定律三 只可寫剛好足以通過目前失敗測試的生產程式碼。

測試與生產程式碼一起編寫，測試只是比生產程式碼早寫幾秒鐘。

2、保持測試整齊

測試程式碼和生產程式碼一樣重要，一樣需要保持足夠的整潔。

測試帶來一切好處。

整齊的單元測試程式碼會為你的程式碼帶來很多好處。測試越髒，程式碼最終會變得越髒。如果遺失了測試，程式碼開始腐爛。

3、整齊的測試

整齊的測試有一個十分重要的要素：可讀性。

測試程式碼要保持明確、整潔，還要有足夠的表達力。在測試中，要以盡可能少的文字表達大量內容。

測試模式：建構-操作-檢驗，

第一環節 建構測試資料

第二環節 操作測試資料

第三環節 驗證操作是否得到期望的結果。

3.1 特定領域的測試語言

使用測試的語言測試，更具可讀性。

3.2 雙重標準

測試API中的程式碼有著與生產程式碼不同的工程標準，要求應當簡單、精悍、足具表達力，但又要和生產程式碼一般有效。

4、每個測試一個斷言

有人認為每個測試函數都應該有且只有一個斷言語句。

每個測試一個概念。

更好的規則或許是每個測試函數中只測試一個概念，只做一件事情。

5、F.I.R.S.T 原則

整齊程式碼應遵循以下規則：

快速（Fast）測試應該夠快。測試應該能快速運作。

獨立（Independent)測試應相互獨立。某個測驗不應為下一個測驗設定條件。

可重複（Repeatable）測試應在任何環境下重複通過。

自足驗證（Self-Validating）測試應該有布林值輸出。無論是失敗還是通過，應直接了當得出結論，而不應該通過查看日誌來確認測試是否通過。

及時（Timely）測試應及時編寫。單元測試應該恰好在使其通過的生產程式碼之前編寫。

6、小結

測試與程式碼同等重要，它保證和增強了生產程式碼的可擴展性、可維護性和可重複使用性。保持測試的整潔，讓測試具有表達力並短小精悍。發明作為特定領域語言的測試API，幫助自己編寫測試。

在實際的開發中，很多團隊，由於各種外部、內部的因素，工期緊、時間少、任務重等諸多因素，很多事沒有TDD、沒有單元測試，即使如此，我們還是要堅持這個原則，慢慢往單元測試這個目標靠近...

你可能喜歡：

金三銀四求職季：程序員面試技巧履歷表篇

如何靠自學成為優秀的全端工程師？