從戴維恩斯坦教數(shù)千軟件開發(fā)者們?nèi)绾胃行У匾詼y試驅(qū)動開發(fā)的10年來，他學(xué)會了掌握測試驅(qū)動開發(fā)的3個關(guān)鍵組成部分：理解它真正是什么，使代碼穩(wěn)定可測，并且獲得實際動手經(jīng)驗。讓我們看這些因素，找到它在你的項目中為有效地使用測試驅(qū)動開發(fā)帶來什么。

在過去10年來，我有教數(shù)千個專業(yè)軟件開發(fā)者如何有效地測試驅(qū)動開發(fā)的權(quán)利。從這些經(jīng)驗中，我學(xué)會了測試驅(qū)動開發(fā)的3個關(guān)鍵因素：理解它真正是什么，使代碼確實可測試，并且獲取一手的經(jīng)驗。讓我們看一看這些因素中的每一個，去看看使用測試驅(qū)動開發(fā)能有效地在你的項目中帶來什么。

1. 理解什么是測試驅(qū)動開發(fā)

有效的測試驅(qū)動開發(fā)的第一主要的組成部分是理解它真正是什么。我發(fā)現(xiàn)有很多關(guān)于如何恰當(dāng)?shù)刈鰷y試驅(qū)動開發(fā)的錯誤想法，并且測試驅(qū)動開發(fā)是那種，如果你做錯了，你會經(jīng)常付出一個很高的代價的實踐。

在這篇短的文章中有更多的介紹測試驅(qū)動開發(fā)，但是我注意到的其中一件事是對人們來講更有挑戰(zhàn)的是人們把測試驅(qū)動開發(fā)想象成測試或者質(zhì)量保證的一種形式。我認為在做測試驅(qū)動開發(fā)時，這是錯誤心態(tài)。

QA的思維模式是在思考可能出現(xiàn)的問題并且找到保證它不再發(fā)生的方法。開發(fā)的思維模式更樂觀，專注于發(fā)生的事情，為了事情順利進行。

不考慮將測試驅(qū)動開發(fā)作為測試代碼的一種方式，我想把測試驅(qū)動開發(fā)想成系統(tǒng)特殊行為的一種方式。這引導(dǎo)我創(chuàng)造非常不同的測試種類，它趨向于將來更有彈性地改變，因為我正在驗證行為而不是測試代碼塊。

術(shù)語“單元測試”也有點誤解。假如我們在寫代碼之前寫測試，那么它實際上不是一次測試，因為當(dāng)我們寫它時，沒有可測試的東西。在這個點上叫它一次測試有點奇怪。反之，我想要把它認為是一種假說。當(dāng)我們在寫代碼之前寫測試時，我們在假定代碼將如何運行，我們需要通過什么，以及將返回什么。

這類似于我們?nèi)绾谓咏茖W(xué)。我們不能隨機運行實驗。我們經(jīng)常開始一種假設(shè)：我們正在嘗試通過或不通過的東西。我們能想出一個實驗去通過或者不通過我們的假設(shè)。把你的實驗考慮成假設(shè)，并且你寫的代碼是為了使測試作為一種實驗通過，來證明這個假設(shè)。

但更大的誤解是，我發(fā)現(xiàn)人們在嘗試TDD時真的會掛起電話，這是他們認為“單元”的意思。對很多開發(fā)來講，當(dāng)他們在“單元測試”里看到術(shù)語“單元”，他們想到一段代碼，像一個方法或者一段聲明，或者甚至一行簡單的代碼。這不是本文中“單元”的含義。就像我理解它的，術(shù)語“單元”被接受成強調(diào)一個功能獨立的單元。

理想情況下，我們后面的行為是對我們正嘗試獲取的驗收標(biāo)準(zhǔn)的間接支持。當(dāng)單元測試也是驗收測試時，我們自然得到需求可追溯性和可驗證性。

一個“行為單元”可能包含一些以合作為工作目的的對象。舉個例子，在拍賣中測試投標(biāo)規(guī)則可能需要一個賣方對象來創(chuàng)建一個拍賣對象和一個投標(biāo)人對象在拍賣中投標(biāo)。有些人將把它作為一次集成測試，因為它包含一些對象的交互。我把它稱為一個單元測試，因為我正在測試投標(biāo)行為的一個單元。

我經(jīng)常發(fā)現(xiàn)當(dāng)我們關(guān)注于可以滿足驗收標(biāo)準(zhǔn)的附加特性時，我們編寫的代碼的維護成本要低得多，因為設(shè)計更容易理解和擴展。

2.使不可測試的代碼可測

學(xué)習(xí)測試驅(qū)動開發(fā)的第二個關(guān)鍵因素是掌握一系列使不可測試的代碼可測試的技術(shù)。很多已存在的代碼是很難測試的，并且當(dāng)我們不得不和那些代碼交互時，很難讓它接受測試。

通過我參觀的很多公司，我在代碼中看到的一個主要問題是為了使用一項服務(wù)，一位顧客將被實例化并且直接呼叫那項服務(wù)。從外部來看，服務(wù)和服務(wù)的客戶端似乎是相同的，不能被拆分。但是，當(dāng)這一系統(tǒng)在整個系統(tǒng)中反復(fù)進行時，它使系統(tǒng)成為一個糾纏在一起的代碼鼠窩，不可能獨立地進行分離和測試。

這個問題的解決方案是一種稱為依賴注入的技術(shù)。你可能很熟悉依賴注入框架的獨立性，比如Spring。但是你能手動地注入依賴，不使用一個框架。代替使一個對象實例化一個服務(wù)然后使用它，我們委托實例化成一個不同的對象，然后將引用傳遞給使用它的客戶端。

允許對服務(wù)的引用傳遞給服務(wù)的使用者，當(dāng)我們測試時讓我們傳入假。它是一個簡單的概念，對做小的、可測試的單元行為和分開整體的代碼是相當(dāng)重要的。

我可以通過幾種虛擬來代替依賴。一個通過簡單的歸類和覆蓋你的代碼交互的方法來創(chuàng)造手工模擬的方法。你可以調(diào)用你的mock的覆蓋方法，而不是調(diào)用真正的依賴關(guān)系，它能返回任何有意義的東西。記住，我們這兒的目標(biāo)是測試我們的代碼可交互與外部依賴，而不是它自身的依賴。

3.做測試驅(qū)動開發(fā)的經(jīng)驗

擁有編寫良好的行為測試和能夠編寫好的、可測試的代碼的技能，只是掌握測試驅(qū)動開發(fā)所需的部分內(nèi)容。第三和最重要的掌握測試驅(qū)動開發(fā)的因素是體驗去做它。當(dāng)開發(fā)者做了測試驅(qū)動開發(fā)并且看到他們的測試如何立即捕捉問題——結(jié)果是他們的代碼有多好——他們開始在項目中做測試驅(qū)動開發(fā)。

在綠色田野項目中學(xué)習(xí)測試驅(qū)動開發(fā)是有用的，因為在遺留代碼上進行測試驅(qū)動開發(fā)會有更多復(fù)雜性。這本身就是一個完成的學(xué)習(xí)領(lǐng)域，在項目中有一些優(yōu)秀的書。我想每一個專業(yè)軟件開發(fā)應(yīng)該讀馬丁福勒的重構(gòu)：改進已有代碼的設(shè)計。而且如果你正在遺留代碼上工作，然后你也應(yīng)該讀邁克爾西羽毛的有效率地同老代碼工作——并且不要忘了查看一下我的書，在遺留程序之上：9種擴展你的軟件生命（和價值）的實踐。

當(dāng)我首次啟動教軟件開發(fā)關(guān)于測試——驅(qū)動開發(fā)，我給他們關(guān)于真正的測試驅(qū)動開發(fā)以及如何使不可測試的代碼可測試的講座。他們知道該怎么做，但我們沒有在一個項目上一起實踐TDD，所以它沒有堅持下去。6個月后我將返回，在團隊中沒有人再做測試驅(qū)動開發(fā)了。

但是當(dāng)我開始包括12個小時的實踐練習(xí)使用測試驅(qū)動開發(fā)作為培訓(xùn)的一部分，我看到人們做了一個徹底的轉(zhuǎn)變，因為他們看到了做TDD的好處。這確實是我們學(xué)習(xí)和得到新行為的唯一的方法：通過做它們并且向我們證明它們是有價值的。你不能從聽別人說一個話題而獲得經(jīng)驗。

理解真正的測試驅(qū)動開發(fā)是什么，知道如何使不可測試的代碼可測，在項目中做測試驅(qū)動開發(fā)獲取實踐經(jīng)驗的好處是掌握測試驅(qū)動開發(fā)的3個關(guān)鍵因素。我發(fā)現(xiàn)當(dāng)開發(fā)有這3個關(guān)鍵因素時，他們?yōu)闇y試驅(qū)動開發(fā)而感到高興，并且在他們的項目中持續(xù)做這件事。

轉(zhuǎn)載于:https://www.cnblogs.com/fengye151/p/11519078.html

總結(jié)

以上是生活随笔為你收集整理的掌握测试驱动开发的3个关键因素（译）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。