TDD：正確的項目開發思路

  從如下僅爲我的觀點，若有疑問和異議，請在評論下留言。

  從事Java開發已經有兩年多，會開始考慮如何保障開發以及維護的穩定性，原由有二，一是公司項目總會有修不完的bug，每次的修復，總會引起新的問題出現，致使維護工做反反覆覆，新工做沒法正常的開展；二是本身有建立網站的計劃，但願可以避免相似公司項目這樣的問題，致使效率低下。實際上，項目的開發，最本質的要求就是：

• 提升開發效率

• 減小維護成本

  爲了實現這兩個要求，看了不少相關的資料，總結出來如下三點：

• 敏捷開發

• 測試驅動開發

• 重構

  敏捷開發屬於方法論，須要經驗豐富的從業者驅動；重構屬於技術活，要靠技術功底深厚的大牛；這兩點不在今天的討論範圍以內，由於都須要經驗的沉澱，可是測試驅動開發不一樣，他屬於意識流，不管是剛入門的菜鳥，仍是工做十年的老鳥，只有具有正確的思考方式，纔可以完成項目的開發。

  測試驅動開發，又名TDD，顧名思義，以測試用例驅動項目開發，與傳統的發開模式不一樣。

• 傳統的開發模式：

  1. 功能點需求分析

  2. 根據功能點編碼

  3. 反覆測試

  4. 修正BUG

  5. 迴歸

  6. 功能上線

• 測試驅動開發模式：

  1. 功能點需求分析

  2. 根據功能點編寫測試用例

  3. 根據測試用例進行編碼

  4. 反覆測試

  5. 修正BUG

  6. 迴歸

  7. 功能上線

  傳統模式和測試驅動開發模式的區別僅在於第二，第三點，這小小的差異，卻對結果有着翻天覆地的影響，可謂差之毫釐，失之千里。測試用例的存在爲何會致使如此大的差距？根據不一樣的開發階段，能夠對測試驅動開發模式進行分析：

• 設計階段

  • 基於需求編寫的測試用例，能夠快速提供產品原型，防止後期需求與描述不符致使返工

  • 基於測試用例的類設計和接口設計，能更好地體現設計意圖

• 開發階段

  • 經過多維度編寫的測試用例，能夠細緻地定位需求的功能點，避免直接編碼致使的考慮不周

  • 根據測試用例的劃分，逐一擊破各個小的功能點，最後集成總功能，屬於良性的開發循環，避免一次性將總功能實現所帶來的巨大壓力

• 代碼重構階段

  • 測試用例能夠保證重構代碼不會影響到非重構部分，爲開發者提供勇氣和信心，不然，會由於代碼的耦合性而難以重構

• 添加新功能階段

  • 添加新的測試用例，但新添加的功能不該該影響舊的測試用例，以保證系統的穩定性

說白了，TDD具有如下幾點優點：

• 對需求負責（需求如何定義，測試用例就如何定義）

• 多個測試用例可精確描述全部的功能點

• 根據功能點，面向對象設計（對象設計，屬性設計，接口設計）【設計的時候，會考慮到開發與到的問題】

• 編碼的目的在於跑通一個個測試用例

• 測試用例至關於指南針，能夠確保重構時和重構後，功能依舊能正確運行

• 新功能開發 ，繼續添加新的測試用例，以保證新功能能在新的測試用例正常運行的同時，確保舊功能也能運行

• 測試代碼要不斷地更新，從最簡單的測試代碼到後來相對穩定的代碼

• 測試代碼是最好的接口文檔，運行測試實例，能夠從代碼層面理解功能