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

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

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

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

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

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

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

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

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

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

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

　　你怎么看待這些問題？我很想聽聽你的想法和建議。不要猶豫，請?jiān)谠u論里分享你的觀點(diǎn)。

相關(guān)鏈接：

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

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