幾個(gè)月前，我去一個(gè)客戶那里，他們?cè)谑褂脺y(cè)試驅(qū)動(dòng)開發(fā)上遇到了很多問題。

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

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

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

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

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

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

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

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

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

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

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

相關(guān)鏈接：

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

測(cè)試驅(qū)動(dòng)開發(fā)(TDD)跟敏捷開發(fā)有沖突