從戴維恩斯坦教數千軟件開發者們如何更有效地以測試驅動開發的10年來，他學會了掌握測試驅動開發的3個關鍵組成部分：理解它真正是什么，使代碼穩定可測，并且獲得實際動手經驗。讓我們看這些因素，找到它在你的項目中為有效地使用測試驅動開發帶來什么。

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

1. 理解什么是測試驅動開發

有效的測試驅動開發的第一主要的組成部分是理解它真正是什么。我發現有很多關于如何恰當地做測試驅動開發的錯誤想法，并且測試驅動開發是那種，如果你做錯了，你會經常付出一個很高的代價的實踐。

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

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

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

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

這類似于我們如何接近科學。我們不能隨機運行實驗。我們經常開始一種假設：我們正在嘗試通過或不通過的東西。我們能想出一個實驗去通過或者不通過我們的假設。把你的實驗考慮成假設，并且你寫的代碼是為了使測試作為一種實驗通過，來證明這個假設。

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

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

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

我經常發現當我們關注于可以滿足驗收標準的附加特性時，我們編寫的代碼的維護成本要低得多，因為設計更容易理解和擴展。

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

學習測試驅動開發的第二個關鍵因素是掌握一系列使不可測試的代碼可測試的技術。很多已存在的代碼是很難測試的，并且當我們不得不和那些代碼交互時，很難讓它接受測試。

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

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

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

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

3.做測試驅動開發的經驗

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

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

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

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

理解真正的測試驅動開發是什么，知道如何使不可測試的代碼可測，在項目中做測試驅動開發獲取實踐經驗的好處是掌握測試驅動開發的3個關鍵因素。我發現當開發有這3個關鍵因素時，他們為測試驅動開發而感到高興，并且在他們的項目中持續做這件事。

轉載于:https://www.cnblogs.com/fengye151/p/11519078.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。