英文原文：“That’s Not TDD” 

　　幾個月前，我去一個客戶那里，他們在使用測試驅動開發上遇到了很多問題。

　　“我們的單元測試用例要半個小時才能跑完，”他說。

　　“你們這不是在做驅動測試開發，”我說。“為了讓測試發揮效能，所有的測試必須在幾秒鐘內能跑完，否則的話，程序員不得不頻繁的停下來等待測試。”

　　“可是怎樣才能讓它們快起來？”他問，“光連接數據庫就需要30秒”

　　于是，我想他展示了一種叫做依賴注入的技術，它能讓你使用一個偽造對象來模擬數據庫。“你并不需要測試你數據庫，”我說。“記住，測試應該是測試那些不受控制的東西，對于測試所依賴的東西，你應該使用模擬工具使它們處于控制之中。”

　　他們遇到的另外一個問題 —— 我最近也是聽到了很多次 —— 是他們的測試程序不但沒起到好的作用，反而成了一個負擔。“我們三天兩頭的要重構程序，關聯的就需要重構測試程序”，這樣的話從客戶那里可以經常聽到。

　　這種問題是他們把TDD想成了QA。TDD不是QA。QA是來保證程序能正確的運行的。TDD是使用斷言(assertion)來表現系統的關鍵特征。在QA里，我們用盡可能多的方法來測試系統中可能會出錯的地方。在TDD里，我們用應盡可能少的測試來表現系統的關鍵特征。

　　我遇到的大多數開發人員都很重視代碼質量，努力寫出高質量的代碼，程序看起來很整潔。但測試用程序也是程序，經常的我能看到測試程序就寫的不是那么好。

　　例如，一些程序員會很認真的把產品程序里的冗余部分清理干凈，但在測試程序中卻留下大量的無用的代碼。任何冗余都不是好事，冗余的測試也是如此，如果程序有變化，冗余的測試會花掉你額外的時間去重構。

　　當系統出問題時，測試程序就體現出來了它最大的價值，至少對我來說是最欣慰的時候。然而，對于系統，任何一個改動只應會讓一個測試失敗。換句話說，沒有任何兩個測試的失敗原因是相同的。這說起來容易做起來難，但如果你尊重這個原則，你將會發現，當你重構代碼時，重構測試程序是會容易多了。

　　目前就說這些問題?？傊?，測試也是程序，它們也要保持高質量。系統中的每個關鍵特征都用一個測試來表現，沒有第二個測試會因為這同一個問題而失敗。

it知識庫：你這不是測試驅動開發，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。