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

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

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

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

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

　　于是，我想他展示了一種叫做依賴注入的技術(shù)，它能讓你使用一個(gè)偽造對(duì)象來模擬數(shù)據(jù)庫。“你并不需要測試你數(shù)據(jù)庫，”我說。“記住，測試應(yīng)該是測試那些不受控制的東西，對(duì)于測試所依賴的東西，你應(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)中可能會(huì)出錯(cuò)的地方。在TDD里，我們用應(yīng)盡可能少的測試來表現(xiàn)系統(tǒng)的關(guān)鍵特征。

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

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

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

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

it知識(shí)庫：你這不是測試驅(qū)動(dòng)開發(fā)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。