關鍵字：TDD 問題 解決 方案
我們組織里曾有許多團隊努力采用測試驅動開發(TDD)[1]。偶爾會有一兩個開發者成功，但是大多數都失敗了。為了更好地找出原因，我調查了團隊 的一些成員，發現即使經過了課堂培訓，還有更多的事情需要做。雖然這里介紹的問題和想法只適用于中大型的公司，但理解這一點能夠幫我們在組織中更好地引入 TDD。
我對組員(他們全都接受過培訓)的調查顯示，以下問題影響了他們：
由于經驗不足，大家發現自己直接TDD比較困難。
TDD培訓的例子比實際應用簡單得多。
需要更多的時間來實驗和嘗試，不要有趕緊發布軟件的壓力。
實際中應用的語言，比如Visual Basic和JavaScript，在單元測試文檔或者課堂練習中從來不會用到。
常常會碰到很多遺留代碼，而培訓時不會介紹如何改進這些代碼。
永遠沒有足夠的時間用來學習──隨時都有盡早交付產品的(人為的)壓力，于是沒有時間學習提高自己。
隱藏的問題
我們已經列舉了這么多癥狀，那么冰山下面隱藏的問題是什么呢?
測試驅動開發并不是很難學。學習階段(指形成根深蒂固的習慣的這段時間)一般會持續2到4個月，期間生產效率有所降低[2]。最終的好處顯而易見，開發者也能自己保持該項技術，但問題是：怎么才能做到這樣?很多開發者僅僅幾天之后就放棄了。
就我見過的方法而言，大多數依賴于課堂培訓(或者e-learning)和一對一的輔導。如果做得好的話，這些方法當然不錯，可以作為整個解決方案的一部分，但是我認為還需要更多的方法。
課程培訓有兩個主要的問題：例子太簡單，與實際問題關系不大;給大家練習的機會不多。
在線培訓(Object Mentor和Industrial Logic，以及其它機構提供的培訓)，其優點是更有深度。然而練習的機會仍然不多。而且在這些課程里，你與其他學生通常沒有交互。聽一聽你同學和同事的問題，能夠加深你的理解。
一對一的輔導只能用于團隊中的幾個人，很難推而廣之。在大型企業里面，專家只有幾個，而需要幫助的人有成千上萬，所以一對一的輔導更是困難。
看書是個很好的方法，但是很少有開發者喜歡通過讀書學習TDD技術，即使有些人發現看書可以緩慢提高其TDD水平。與其它在線教程類似，看書仍然是只能一個人學習。
最后：遺留代碼使得TDD難上加難。開發者當然會問這樣的問題：“這些對象緊密耦合，怎樣才能測試它們?這些代碼太復雜了，怎樣才能測試這個算法?”
一個解決方法
那怎樣才是好的解決辦法呢?前面的方法主要有兩個問題：沒有深度、缺乏協作。一個完整的解決方案需要結合使用多種學習模式，并需要包含以下多種因素。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
