如果這種編程風格在理論上很偉大，實踐中卻行不通，那麼我們又何必在一棵樹上“吊死”？
作者 | Mike Cronin
你沒看錯，我認為測試驅動開發（Test Driven Development，TDD）很糟糕。更糟糕的是，就好像一個別有用心的人巧妙地掩蓋了某些瑕疵，給年輕的開發人員一些不切實際的目標。因此，我想半開玩笑地問你，為一個尚不存在的功能編寫測試，你是瘋了嗎？
為什麼我會這樣想？
本週我和某位喜歡TDD的開發人員談了談真實的經歷。我問他們使用TDD的情況，他們滔滔不絕地談到了所有的好處。但當我更進一步問：“那麼，你會在工作中用嗎？”他們的回答就大相徑庭了。
“這個，關於TDD嘛……”
有人說：“沒有時間。”有人說：“我們不是這種文化。”還有人說：“我和我女朋友一直在用TDD，只是你不認識她，她去了另一所學校。”如果TDD真的很棒的話，為什麼採用這種方式的人卻不多呢？這特別讓人失望，因為在訓練營的時候，我從來沒有看到任何一位老師採用TDD，但他們都談到了你應該如何利用TDD。聽到每個人都反覆談論TDD，我的心情很複雜，因為在內心深處我永遠都不明白為什麼反著做更好。
那麼，TDD究竟有哪些優勢呢？
那些鼓吹TDD的人承認，採用TDD確實會降低速度。但是，他們聲稱生成的代碼會非常乾淨，且思路清晰，從長遠來看，還是能夠節省時間。但是我覺得TDD需要花費這麼多時間，原因還是它的......效率低下。這一點從某天某人嘗試TDD的過程中就可以明顯地看出來。
事情的經過
那天，當某位開發說向我展示TDD時，我特別興奮。我們選擇了一個功能，然後從一個函數著手，設計了一個測試，最後看著它失敗了。然後又從這個函數開始，大約過了十分鐘後，他們停下來了。因為他們注意到我們實現函數的方式決定了測試實際上檢測不到。於是，我們不得不停止這個功能，然後回去重新寫測試。
後來，我們又開始準備測試那個函數，結果卻發現我們不知道這個功能如何與系統的其他部分進行交互。於是，我們開始研究代碼，想看看這個函數會怎樣反應。我們修改了那個功能函數，然後用日誌記錄了結果。再後來，我們發現如果修改配置文件或修改其他小功能的話會更容易，於是，我們又很快改了一遍。雖然我們花了不少時間，但是終於搞明白了這個功能與系統的交互方式。這時，我又發現：1）這個功能的代碼已經寫完了；2）我們的測試又一次寫錯了。
為什麼我們嘗試TDD失敗了？
因為開發軟件的工作並不簡單。當然，在製作玩具應用程序時，TDD聽起來很美好。但在現實生活中，各個功能的複雜度遠不止：“函數X接收一個名字某某，然後輸出某某你好”。產品的要求往往會在開發期間發生變化，或者你發現這個功能無法按要求運行。也許是你原來的理解有誤，你必須重新開始。
所有這些情況都屬正常，但每次停下來重新編寫測試，都會讓問題變得更糟。相比之下，先寫代碼，然後手動執行QA測試，最後再通過自動化測試模擬這些場景，這樣的流程則更為簡單。如果已經有人為你準備好了正確的測試，那麼你自然可以繼續下一個功能或重構，而不必擔心會破壞其他功能。將測試當成防護手段，而非導向，才能發揮測試的最大作用，同時還不必擔心需要事先預知所有的問題。
但TDD確實有一些優點！
TDD也有很多值得關注的地方。事實上，除了測試之外，TDD的其他方面都很好。TDD背後的想法是，只有你坐下來認真思考功能，才能寫出測試。這很好！有太多開發人員（包括我自己）不管不顧一頭扎進編程的工作裡，卻不思考這些代碼實際上需要實現什麼功能。其實，你只需要記住函數的目標和要求，TDD就起作用了，實在沒有必要編寫測試。
總結
本文之所以討論這個話題，是因為測試很重要。
沒有經過測試就放入生產的應用程序就像在沒有車道的高速公路上行駛。我只想說，TDD就像在實際鋪設之前，畫了一條高速公路給你。也許你不同意，也許你特別喜歡TDD，而且每天都在使用。但如果你不使用，也沒什麼大不了！我們必須誠實面對自己。如果某種編程風格在理論上很偉大，實踐中卻行不通，那麼就讓我們取其精華棄其糟粕。但令我費解的一點在於：編程的方式有很多種，我們又何必在一棵樹上“吊死”？
話說回來，行為驅動開發（Behavior Driven Development，即BDD）是完美無瑕的，如果你不用，你就是傻瓜。
原文：https://itnext.io/test-driven-development-is-dumb-fight-me-a38b3033280c
閱讀更多 IT架構 的文章
