不要宗教化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，找到最合適團隊的，纔是最好的。