注：本文轉載自外刊IT評論
幾個月前，我去一個客戶那裡，他們在使用測試驅動開發上遇到了很多問題。
“我們的單元測試用例要半個小時才能跑完，”他說。
“你們這不是在做驅動測試開發，”我說。“為了讓測試發揮效能，所有的測試必須在幾秒鐘內能跑完，否則的話，程式設計師不得不頻繁的停下來等待測試。”
“可是怎樣才能讓它們快起來？”他問，“光連線資料庫就需要30秒”
於是，我想他展示了一種叫做依賴注入的技術，它能讓你使用一個偽造物件來模擬資料庫。“你並不需要測試你資料庫，”我說。“記住，測試應該是測試那些不受控制的東西，對於測試所依賴的東西，你應該使用模擬工具使它們處於控制之中。”
他們遇到的另外一個問題—我最近也是聽到了很多次—是他們的測試程式不但沒起到好的作用，反而成了一個負擔。“我們三天兩頭的要重構程式，關聯的就需要重構測試程式”，這樣的話從客戶那裡可以經常聽到。
這種問題是他們把TDD想成了QA。TDD不是QA。QA是來保證程式能正確的執行的。TDD是使用斷言(assertion)來表現系統的關鍵特徵。在QA裡，我們用盡可能多的方法來測試系統中可能會出錯的地方。在TDD裡，我們用應儘可能少的測試來表現系統的關鍵特徵。
我遇到的大多數開發人員都很重視程式碼質量，努力寫出高質量的程式碼，程式看起來很整潔。但測試用程式也是程式，經常的我能看到測試程式就寫的不是那麼好。
例如，一些程式設計師會很認真的把產品程式裡的冗餘部分清理乾淨，但在測試程式中卻留下大量的無用的程式碼。任何冗餘都不是好事，冗餘的測試也是如此，如果程式有變化，冗餘的測試會花掉你額外的時間去重構。
當系統出問題時，測試程式就體現出來了它最大的價值，至少對我來說是最欣慰的時候。然而，對於系統，任何一個改動只應會讓一個測試失敗。換句話說，沒有任何兩個測試的失敗原因是相同的。這說起來容易做起來難，但如果你尊重這個原則，你將會發現，當你重構程式碼時，重構測試程式是會容易多了。
目前就說這些問題。總之，測試也是程式，它們也要保持高質量。系統中的每個關鍵特徵都用一個測試來表現，沒有第二個測試會因為這同一個問題而失敗。
你怎麼看待這些問題？我很想聽聽你的想法和建議。不要猶豫，請在評論裡分享你的觀點。