從開發的角度來講，先把變數、函數依照一定的命名、格式組織好，接下來，開始寫程式碼，在業界，很多提倡測試驅動開發，接著跟大家聊一下單元測試。
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、沒有單元測試，即使如此，我們還是要堅持這個原則，慢慢往單元測試這個目標靠近...
你可能喜歡：
