TDD的實施細節應該怎樣做

　　以前也有看過一些TDD的資料，但一直沒有在實際的項目中實踐過。最近可能有一個新的項目，不是特別大，想采用Scrum和TDD小試身手。先介紹一下我們以前項目的開發流程：

　　1.拿下項目，需求調研分析，編寫需求用例(如果客戶沒有要求，需求規格說明書都不寫)

　　基本上需求用例就是說明什么人，做什么事情，怎么做，達到什么目的，有什么要求這些。

　　2.然后分析領域對象，分析業務流程和場景。并最終生成數據庫物理模型。

　　3.概要設計，其實也沒什么，就是數據庫結構，還有用例描述加一些時序圖。

　　4.根據需求用例，編寫測試用例。

　　5.開發人員進行開發，有時項目緊的時候，單元測試都不寫(這個項目沒有明文要求)，主要靠開發人員個人意愿。

　　6.根據周期定期進行打包測試。我一般會每周build兩次，親自操作一下業務流程，有問題提出修改。這個過程測試人員未參與。

　　7.測試人員進入，按模塊完成的先后順序，持續的測試修改。

　　以前的項目基本上是采用領域驅動的方式進行一步步開發的?，F在打算采用TDD方式，現有一些細節疑問，打算請教一下實施了TDD的各種牛。

　　1.TDD方式是不是不用寫需求說明書了?

　　2.分析領域對象，分析業務流程和場景。并最終生成數據庫物理模型。這一步是不是在TDD之前完成?

　　3.不寫概要設計，由需求用例直接跳入TDD開發?

　　4.測試用例是不是需求用例的細化和規范?

　　5.TDD中的test是基于單元測試，還是基于需求測試?

　　6.如果是單元測試，自然由開發人員完成。如果TDD是基于需求測試，那么開發人員是否需要測試人員配合?

　　最后一個問題是：大家有結對編程的習慣嗎?在實踐過程中結對是否高效?反正我是覺得結對不會太高效的，主要是基于項目人員的配置本來就有成本在那里，而且人員水平也不一樣。我的觀點是一個經驗豐富的帶一兩個新手共同開發一個模塊，但并不需要結對的方式。

　　ok,問題完了。等大家拍磚。

　　問題補充

　　humaeks 寫道

　　個人的幾點愚見，有點零亂：

　　1. 首先明確unit test和功能測試不一樣，參與的人也不一樣。

　　2. 設計完了再入TDD階段，寫UT的過程其實也是校驗測試的過程，如果測試不好寫，就需要review設計。這里插播一下，既然考慮采用DDD，應該先出來CDM，然后java OO與CDM對應，剩下才是設計物理模型和持久層

　　3. 傳統意義上的TDD指的是unit test。背后很重要的一個思想是先寫測試有助于寫出clean code that works, 或者說是just enough的代碼，實踐上需要權衡。對程序員的編程技巧要求高，在我的團隊成員中，從零到真的能寫出“單元”測試，需要每天抽一小時1 on 1 code review一個月以上。

　　需要程序員有邏輯拆分以及一些coding技巧，看implementation patterns / clean code 這兩本書會有幫助，但關鍵還是每天的code review給及時反饋。

　　4. 100%覆蓋是不切實際的東西，尤其是初次嘗試TDD，可以采用以點帶面的方式，讓部分成員先嘗試到TDD帶來的好處，然后在團隊中傳播;

　　5. 成員水平不一樣可以采取結對方式提升人員水平，但成本回收周期長，基本不會對本項目(3月內的項目)產生benefit，但遇到有好苗子要堅決培養，否則日后還是會死，留不留得住人，就是另外一個管理topic了。

原文轉自：http://www.kjueaiud.com