本文關(guān)鍵詞：單元測試的藝術(shù)，由筆耕文化傳播整理發(fā)布。

> 其他綜合 > 單元測試的藝術(shù) : 第2版 1.3　集成測試 2014-08-08 11:20:04         我要投稿   

本文所屬圖書 > 單元測試的藝術(shù) : 第2版

本書是經(jīng)典的單元測試學(xué)習(xí)指南，分四部分全面介紹了單元測試技術(shù)。第一部分闡述單元測試基本概念，包括如何使用測試框架。第二部分討論破除依賴的高級技術(shù)：模擬對象、存根和隔離框架，包括重構(gòu)代碼以使用這些技  立即去當(dāng)當(dāng)網(wǎng)訂購

任何測試，如果它運行速度不快，結(jié)果不穩(wěn)定，或者要用到被測試單元的一個或多個真實依賴物，我就認為它是集成測試。例如，如果一個測試要使用真實的系統(tǒng)時間，真實的文件系統(tǒng)，或者一個真實的數(shù)據(jù)庫，那這個測試就進入了集成測試的領(lǐng)域。

例如，如果一個測試不能控制系統(tǒng)時間，在代碼中使用了當(dāng)前時間DateTime.Now，那么每次測試執(zhí)行使用的都是不同的時間，因此每次測試本質(zhì)上都是不同的，那么這個測試就不穩(wěn)定了。

這種測試本身并不是一件壞事。我認為集成測試和單元測試具有同等重要的地位，但是這兩種測試應(yīng)該彼此分開，以營造一種“綠色安全區(qū)”的感覺。這一點我會在本書后面的章節(jié)討論。

如果一個測試使用真實的數(shù)據(jù)庫，那么和那些只使用內(nèi)存中的偽數(shù)據(jù)的測試相比，這種測試的行為痕跡更難以消除，從這個意義上說它就不是只在內(nèi)存中運行了。這種測試的運行時間也會更長，這個問題也是無法控制的。單元測試運行應(yīng)該很快。集成測試通常會慢很多。如果你有成百上千個測試的話，半秒鐘都是至關(guān)重要的。

集成測試還可能帶來另外一個問題：一次測試的東西太多。

如果汽車壞了該怎么辦？先不說怎么修好它，你怎么找到問題出在哪呢？一個汽車的發(fā)動機由許多子系統(tǒng)組成，這些子系統(tǒng)協(xié)同工作，每個子系統(tǒng)都依靠其他的子系統(tǒng)的幫助產(chǎn)生最終的結(jié)果：一輛飛馳的汽車。如果汽車不動了，問題可能出在這些子系統(tǒng)中的任何一個，或者多個。這些子系統(tǒng)（或?qū)哟危┑募墒沟闷嚹軌蚬ぷ鳌．?dāng)汽車上路時，你可以把它能否開動看成是對這些部件的一個終極集成測試。如果這個測試失敗了，那所有的部件就都失敗了；如果這個測試成功了，那所有的部件也就都成功了。

軟件也是同樣的道理。大部分開發(fā)人員是通過用戶界面的最終功能來測試軟件的功能。單擊一個按鈕會觸發(fā)一系列的事件，類和組件協(xié)同工作產(chǎn)生最終的結(jié)果。如果測試失敗了，所有這些軟件組件作為一個整體就失敗了，而且很難找到到底是什么導(dǎo)致了整體操作的失�。▍⒁妶D1-2）。

 

正如Bill Hetzel在The Complete Guide to Software Testing（Wiley，1993）一書中定義的，集成測試是“一個循序漸進的測試，軟硬件相結(jié)合并進行測試直到整個系統(tǒng)集成在一起”。但是很多人每天做的不是系統(tǒng)集成測試，而是開發(fā)和單元測試， 這個定義并不太適用。

這里有一個更好的集成測試定義。

定義　集成測試是對一個工作單元進行的測試，這個測試對被測試的工作單元沒

有完全的控制，并使用該單元的一個或多個真實依賴物，例如時間、網(wǎng)絡(luò)、數(shù)據(jù)庫、線程或隨機數(shù)產(chǎn)生器等。

總的來說，集成測試會使用真實依賴物，而單元測試則把被測試單元和其依賴物隔離開，以保證單元測試結(jié)果高度穩(wěn)定，還可以輕易控制和模擬被測試單元行為的任何方面。

1.2節(jié)中列出的問題可以幫助你認識到集成測試的一些缺點。我們接下來要定義期望在優(yōu)秀的單元測試中看到的特質(zhì)。

與自動化單元測試相比，非自動化集成測試的缺點

讓我們把1.2節(jié)中的問題同樣應(yīng)用在集成測試上，同時思考在真實世界中使用單元測試的目的。

我兩周前寫的一個單元測試，今天還能運行并得到結(jié)果嗎？幾個月前寫的呢？幾年前寫的呢？

如果回答是“不能”，那你怎么知道自己是不是已經(jīng)破壞了以前實現(xiàn)的某個功能？在應(yīng)用程序的生命周期中，代碼經(jīng)常會變化。如果在修改代碼之后，你不能（或者不愿意）對之前所有的功能進行測試，就有可能破壞了某個功能而毫不知情。我把這種情況稱為“偶然引入缺陷”。在軟件項目快結(jié)束時，開發(fā)人員承受著壓力修復(fù)已有的缺陷，“偶然引入缺陷”的情況會經(jīng)常發(fā)生。有時開發(fā)人員會在修復(fù)舊缺陷的時候無意間引入新缺陷。如果在破壞功能后三分鐘內(nèi)就能發(fā)現(xiàn)問題，那該多好��！在本書后面的章節(jié)中，你會了解如何做到這一點。

定義　回歸是以前運行良好但是現(xiàn)在不工作的一個或多個工作單元。

我兩個月前寫的單元測試，團隊里任何一個人都能運行它們并得到結(jié)果嗎？

這個問題和上一個屬于一個范疇，但比上一個問題要求更高。當(dāng)你做改動時，，需要保證自己不會破壞別人的代碼。許多開發(fā)人員都害怕修改以前系統(tǒng)中的遺留代碼，就是擔(dān)心不知道有什么別的代碼依賴他們要改動的部分。簡言之，他們不知道系統(tǒng)修改后的狀態(tài)是否穩(wěn)定。

應(yīng)用程序是不是還正常工作是很令人擔(dān)心的，尤其代碼還不是你自己寫的。如果知道自己不會破壞任何功能，你就比較有信心接手不太熟悉的代碼了，因為有單元測試這個安全網(wǎng)。

優(yōu)秀的單元測試可被任何人訪問和運行。

定義　遺留代碼在維基百科中定義為“與一個不再受支持或繼續(xù)生產(chǎn)的操作系統(tǒng)，或其他計算機技術(shù)相關(guān)的源代碼”，但是很多公司把任何比當(dāng)前維護的應(yīng)用更老舊的版本都稱為遺留代碼。這個詞經(jīng)常用來指代那些難以使用，難以測試，通常也更難以閱讀的代碼。

有一個客戶曾經(jīng)以一種很實際的方式定義遺留代碼：“能運行的代碼”。很多人喜歡把遺留代碼定義為“沒有測試的代碼”。Michael Feathers在《修改代碼的藝術(shù)》（Prentice Hall，2004）中把“沒有測試的代碼”作為遺留代碼的正式定義，在閱讀本書時我們也需要對此定義加以考慮。

我能在幾分鐘內(nèi)跑完我寫過的所有單元測試嗎？

如果你不能很快運行完測試（幾秒鐘完成要好于幾分鐘完成），就不會經(jīng)常運行它們（每天或者每周，有時甚至每月運行）。問題是，如果修改代碼，你需要盡早得到反饋，好知道自己是不是破壞了什么功能。運行測試的時間間隔越長，你對系統(tǒng)做未測試的修改越多，出現(xiàn)問題的時候需要找尋缺陷的地方就越多。

優(yōu)秀的測試需要能夠快速運行。

我能一鍵運行我寫過的所有單元測試嗎？

如果不能，那可能意味著你需要對運行測試的機器進行配置，讓測試能夠正確運行（比如設(shè)置數(shù)據(jù)庫的連接字符串），或者單元測試不是完全自動化的。如果不能完全自動化單元測試，你很可能會避免重復(fù)運行這些測試，團隊里的其他人也一樣。

沒有人喜歡費工夫配置然后運行測試，而結(jié)果只是為了保證系統(tǒng)還能運行。開發(fā)人員有著更重要的任務(wù)，比如在系統(tǒng)中增加更多功能。

優(yōu)秀的測試應(yīng)該無需修改就能運行，不需要手工配置。

我能在幾分鐘內(nèi)寫出一個基本的測試嗎？

辨別集成測試的一個最簡單方法就是：集成測試需要花時間進行正確的準(zhǔn)備和實施，不能直接執(zhí)行。編寫集成測試需要花費時間，因為它涉及內(nèi)部，有時還有外部的依賴。（數(shù)據(jù)庫可以看做外部依賴。）如果不對測試進行自動化，依賴就不是一個太大的問題，但是你也就失去了享受自動化測試所有好處的機會。編寫測試的難度越高，你編寫更多測試的可能性就越小，對所擔(dān)心的“大問題”之外的東西也會關(guān)注越少。單元測試的一個特點就是會測試可能出問題的每一處細節(jié)，而不只是關(guān)注大問題。人們常常會驚訝：有很多缺陷正是在他們認為簡單正確的代碼里找到的。

當(dāng)你只關(guān)注大的測試時，測試的邏輯覆蓋率就會比較低，代碼中核心邏輯的很多部分不會測到（雖然你可能覆蓋到了較多的組件），這樣就可能會出現(xiàn)沒有考慮到的缺陷。

一旦找到了想用來測試具體對象模型的模式，你就應(yīng)該能很快地輕松編寫出優(yōu)秀的測試。一個小小的警告：對一個以前沒有做過單元測試的對象模型，即便是有經(jīng)驗的單元測試人員，也需要花30分鐘或者更長時間才能寫出第一個單元測試。這種摸索工作是難免的，也是預(yù)料之中的。對這個對象模型的第二個以及之后的測試應(yīng)該很容易就能完成了。

到現(xiàn)在，我已經(jīng)解釋了什么測試不是單元測試，以及有用的測試應(yīng)具有什么特征�；谶@些，現(xiàn)在我可以開始回答這一章提出的主要問題了：什么是優(yōu)秀的單元測試？

點擊復(fù)制鏈接 與好友分享!回本站首頁 您對本文章有什么意見或著疑問嗎？請到論壇討論您的關(guān)注和建議是我們前行的參考和動力   上一篇：1.2　優(yōu)秀單元測試的特性 下一篇：1.4　什么是優(yōu)秀的單元測試 相關(guān)文章

1.1 簡介和CMMI入門

1.1.1 cmmi入門

1.1.2 短語“CMMI 符合性”在本書

1.2 敏捷方法入門

1.2.1 敏捷原則和實踐

1.2.2 書中使用的敏捷術(shù)語

2.1 本章的學(xué)習(xí)內(nèi)容

2.8.1 精簡多余過程以縮短響應(yīng)時間

2.10 了解CMMI模型的目的，幫助組織

2.11 使用CMMI模型時可以通過不同的

圖文推薦

  本文關(guān)鍵詞：單元測試的藝術(shù)，由筆耕文化傳播整理發(fā)布。

本文編號：368416