放棄測試優先式開發（TDD）

測試優先或測試驅動開發（TDD）是你在編寫程式前先編寫測試的軟體開發方法。你編寫程式來通過測試，擴充套件測試或增加測試然後再擴充套件程式功能來通過這些測試。你先花費時間建立一系列的測試，然後你可以在每次程式修改時自動執行測試。這是為了確保每時每刻程式都能夠執行並通過測試。你週期性地重構你的程式來提高它的結構並讓它易讀易改。

外界宣稱測試優先式開發提高了測試覆蓋率，並且在不改變現有功能基礎上，能夠更簡單的改變程式。測試的作用就像文件一樣，你有了一個關於程式應該做什麼的詳細又抽象的描述。

幾個月前，我謹慎的決定體驗測試優先式開發。作為一個退休的程式設計師，我編寫的是我私人的專案，而不是一個有文件說明的客戶端。所以我在此所說的話或許僅僅適用於沒有嚴格程式文件的情況。

起初，我發現這個方法（測試驅動開發）很有用。但我開始實現一個 GUI 時，編寫測試很困難，而且我認為編寫測試所花費的時間並不值得。然後，我並沒有完全（或許是不純粹地）按照TDD的要求去實現，所以我沒有對所有東西做自動化測試，有時在編寫測試前就實現了一些東西。

但是，我並不是因為編寫 GUI 自動化測試的（眾所周知的）困難而放棄 TDD 。我放棄是因為我認為它在程式設計中鼓勵保守主義，它鼓勵你設計能通過測試的決策，而不是符合使用者的正確決策，它使你專注於細節而不是架構，並且它並不能適用於主要的一類程式問題——那些由意外的資料引起的問題。

• 因為你想確保你總是可以通過大多數的測試，當你改變並擴充套件程式時你傾向於思考這一點。你因此不情願做出會導致大量測試失敗的大範圍的變更。從心理上講，你變得保守並避免破壞大量測試。
• 往往對程式設計做測試比其他更容易。有時，最棒的設計是很難測試的，所以你不情願採取這種方法，因為你知道你將花費大量時間設計並編寫測試（對於我來說真的是一件無聊的事）。
• 對於我來說最嚴重的問題是 TDD 鼓勵專注於整理細節來通過測試，而不是把程式看做一個整體。我每次開始程式設計時只有有限的上機時間，並且需要花費時間審視並思考程式整體。我認為這帶來優雅又優秀的結構化程式。但是 TDD 讓你深入程式不同部分的細節，很少能夠退後一步審視大局。
• 根據我的經驗，很多程式出現失敗是因為處理的資料並不是程式所期待的。編寫能夠精確反映出你將要處理的壞資料的「壞資料」測試很困難，因為你需要成為一個領域專家並理解資料。「純粹主義者」解決這點，當然，那就是你設計了資料校驗檢查，所以你不需要處理壞資料。但是現實中通常很難定義什麼是「正確的資料」，並且有時你不得不處理你得到的資料而不是你預期的資料。

所以，我回到原點開始先寫程式碼，然後寫測試。我繼續在有意義的地方做自動化測試，但在我能清楚讀懂程式碼並理解它做什麼的時候，我不會花費大量荒謬的時間編寫測試。思考優先比測試優先是一條更好的路。

附言。我很確定 TDD 純粹主義者會說我做的不正確，所以沒有真正從 TDD 受益。或許他們是對的。但是我還沒有找到狂熱者能夠說服我。

打賞支援我翻譯更多好文章，謝謝！

打賞譯者