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

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

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

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

　　于是，我想他展示了一種叫做依賴注入的技術(shù)，它能讓你使用一個偽造對象來模擬數(shù)據(jù)庫！澳悴⒉恍枰獪y試你數(shù)據(jù)庫，”我說。“記住，測試應(yīng)該是測試那些不受控制的東西，對于測試所依賴的東西，你應(yīng)該使用模擬工具使它們處于控制之中！

　　他們遇到的另外一個問題?我近也是聽到了很多次?是他們的測試程序不但沒起到好的作用，反而成了一個負(fù)擔(dān)！拔覀?nèi)靸深^的要重構(gòu)程序，關(guān)聯(lián)的需要重構(gòu)測試程序”，這樣的話從客戶那里可以經(jīng)常聽到。

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

　　我遇到的大多數(shù)開發(fā)人員都很重視代碼質(zhì)量，努力寫出高質(zhì)量的代碼，程序看起來很整潔。但測試用程序也是程序，經(jīng)常的我能看到測試程序?qū)懙牟皇悄敲春谩?/FONT>

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

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

　　目前說這些問題。總之，測試也是程序，它們也要保持高質(zhì)量。系統(tǒng)中的每個關(guān)鍵特征都用一個測試來表現(xiàn)，沒有第二個測試會因為這同一個問題而失敗。

　　你怎么看待這些問題？我很想聽聽你的想法和建議。不要猶豫，請在評論里分享你的觀點。

相關(guān)鏈接：

我們的測試驅(qū)動開發(fā)經(jīng)驗

測試驅(qū)動開發(fā)(TDD)跟敏捷開發(fā)有沖突