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

敏捷程式設計的概念出來已經很久了，期間湧現出了很多名詞，什麼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，找到最合適團隊的，才是最好的。