初步認識TDD

　　TDD，測試驅動開發（Test Driven Development）是極限編程中倡導的程序開發方法，以其倡導先寫測試程序，而後編碼實現其功能得名。本文將對TDD有一個較爲系統的認識。

   基礎屬性

　　起源：20世紀90年代。

　　性質：一種由極限編程倡導的程序開發方法。

　　中心思想：先寫測試程序，而後編碼實現其功能。

　　目的：取得快速反饋並使用「illustrate the main line」方法來構建程序。

   開發方式

　　一、戴兩頂帽子的開發方式

　　（1）戴實現功能的帽子,在測試的輔助下,快速實現其功能。

　　（2）戴上重構的帽子,在測試的保護下,經過去除冗餘的代碼,提升代碼質量。

　　二、中心思想

　　測試驅動着整個開發過程。

　　（1）驅動代碼的設計和功能的實現。

　　（2）驅動代碼的再設計和重構。

   測 試

　　一、特徵

　　測試驅動開發是需求分析和詳細設計的範疇,在代碼基本完畢之後,而且這些測試也成爲單元測試的一個部分。

　　二、要點

　　可讀性甚至比生產代碼更重要，明確，簡潔，足夠的表達力。

　　三、通常模式

　　構造數據 — 操做數據 — 檢驗數據

　　四、遵循的規則

　　（1）單個測試中斷言數量應該最小化，能夠快速方便地理解其結論。

　　（2）每一個測試一個概念，即每一個測試函數只作一件事。

　　（3）F.I.R.S.T原則

　　　　快    速（First）：可以快速運行。

　　　　獨    立（Independence）：可單獨運行每一個測試，也就是說能夠任何順序運行測試。

　　　　可重複（Repeat）：在任何環境中測試均能經過。

　　　　自動驗證（Spontaneous Verification）：應有布爾值輸出。

　　　　及    時（Timely）：應在生產代碼以前編寫。

   TDD三定律

　　一、在編寫不能經過的單元測試前,不可編寫生產代碼。

　　二、只可編寫恰好沒法經過的單元測試,不能編譯也算不經過。

　　三、只可編寫恰好足以經過當前失敗測試的生產代碼。

　　總的來講就是先寫測試再寫生產代碼，寫一個測試就應該當即寫它的實現代碼。

   評 價

　　一、正面

　　（1）能夠有效避免過分設計帶來的浪費。

　　（2）可讓開發者在開發中擁有更全面的視角。

　　（3）確保全部需求都能被照顧到。

　　二、負面

　　（1）過分關注用例和測試案例,而不是設計自己。

　　（2）可能會致使單元測試的覆蓋度不夠,好比可能缺少邊界測試。

　　（3）放慢開發實際代碼的速度。

　　（4）對於GUI,資料庫和Web應用而言,構造單元測試比較困難,若強行構造單元測試,反而會給維護帶來額外的工做量。

　　（5）test case  並無那麼好寫,若是說咱們開發的Test Case是用來保證咱們代碼實現的正確性，那麼，誰又來保證咱們的Test Case的正確性呢？

   個人感悟

　　使用TDD完成過一個小遊戲項目，感受TDD的開發方式讓我以爲有了另外一種思惟開發方式，從這個項目的各個功能點來寫測試，並經過測試來實現咱們的生產代碼。之前完成一個項目是自上而下的思惟，就是站在一個宏觀的角度，來全局總覽這個項目，那麼最開始的時候就得考慮不少，這個時候最容易陷入細節誤區了，即會細化到某些細節難以控制本身的思惟。如今接觸TDD以後，給個人感受就是自下而上了。不考慮全局的東西，我一個小功能一個小功能的實現，曾經是從樹頂來作，如今是從樹根了，每個根節點實現了我往上一層一層加起來，最後就是一棵樹了，哈哈~

 

ps：本文內容如果有誤或者迷糊，還請指正或指出。