敏捷編程的概念出來已經很久了，期間湧現出了很多名詞，什麽XP啊，Scrum啊，被很多人所推崇。

我想說的是TDD這個東西，也是被很多人認為是保證軟件質量的法寶，一旦選擇了TDD方式，就自動的獲得了設計代碼的能力，這其實只是一種假設，不是一種必然。我覺得這些都是錯的，不要認為TDD了，就能解決現在的問題。

首先，TDD意味著還未開發就要寫大量的測試用例，這本來就是和敏捷開發的初衷是違背的，因為寫大量的測試代碼，本身就不是敏捷的事情。

Ruby on Rails的作者，在TTD大行其道的時候，冒死說出了TDD已死的，TTD的缺點得到了程序員們重新思考和討論。那麽TDD到底有哪些事情讓我這麽不爽呢？

首先，維護測試代碼的成本很高，目前我所在的團隊部分開發正在TDD，這個教條主義式的編程方式，讓開發花了大量的時間寫測試用例，不要忘了，測試代碼也是代碼，所有的代碼維護成本都是差不多的。一旦業務變更，意味著測試代碼需要修改。

其次，TDD的開發方式，我一直認為是反直覺的。試想，你要實現一段程序邏輯，你還不知道會出哪些問題的情況下，先把可能的結果都枚舉了一遍，但很多場景下，你只能考慮到有限的一些結果，對於其它的一些問題，更可能是在開發過程中才意識到的。

TDD中的Mock也是一個難題，確定Mock點就會傷掉一部分腦筋，大量使用Mock只是將功能點一個個的分離出來測試，而無法進行集成功能測試。TDD開發人員，在項目工期緊，壓力大的環境下，最終淪為為TDD而TDD，寫完交差，沒有後期維護。

我比較厭惡編程屆這種跟風的潮流，總覺得新出來的名詞，不學幾個就是土的掉渣，落伍的人。比較反感強推某種方法論，而不考慮實際情況。

TDD不是銀彈。尤其是在需要敏捷開發的互聯網行業，版本的叠代速度非常快，而TDD的這種做法是非常不適合的。我覺得TDD最適合在常規的產品軟件中使用，因為版本叠代平穩，周期可控。

不能一棍子打死TDD，TDD確實有它的不少優點，但是衡量是否值得TDD的標準就是投入成本和產出效益之間是否平衡，而不能不顧實際的盲目推崇。軟件測試不是只有TDD，找到最合適團隊的，才是最好的。

本文出自 “一只博客” 博客，請務必保留此出處http://cnn237111.blog.51cto.com/2359144/1968160

不要宗教化TDD(測試驅動開發)