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

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、沒有單元測試，即使如此，我們還是要堅持這一原則，慢慢往單元測試這個目標靠近...

你可能喜歡：

本文原創發布php中文網，轉載請注明出處，感謝您的尊重！

總結

以上是生活随笔為你收集整理的php 单元测试分享,今日分享：代码整洁之道- 单元测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。