第六章:用stub進(jìn)行粗粒度測試
本章內(nèi)容:
介紹stub
使用嵌入式服務(wù)器代替真正的網(wǎng)絡(luò)服務(wù)器
用stub單元測試一個(gè)HTTP連接案例
當(dāng)你開發(fā)自己的應(yīng)用程序時(shí)，你可能會(huì)發(fā)現(xiàn)你想要測試的代碼段依賴于其它的類，而它們本身也依賴于另一些類，這些類則要依賴于開發(fā)環(huán)境.
由于程序依賴于開發(fā)環(huán)境，編寫單元測試成為了一個(gè)挑戰(zhàn).你所做的測試需要具有穩(wěn)定性，當(dāng)你一遍又一遍地運(yùn)行它們，產(chǎn)生的結(jié)果必須是一致的.所以，你需要找到一個(gè)方法來控制運(yùn)行環(huán)境.一個(gè)解決的辦法是建立真正的需求環(huán)境作為測試的一部分，并在其中運(yùn)行測試.在某些情況下，這種方法是可行的，同時(shí)帶來了額外的價(jià)值.但是，只有你在開發(fā)平臺(tái)上建立真實(shí)環(huán)境，測試才工作得好.事實(shí)上，這種情況不是總是會(huì)出現(xiàn)的.
例如，你的應(yīng)用程序使用http連接由第三方提供web服務(wù)器，但是在你的開發(fā)環(huán)境里通常并不存在那樣一個(gè)可用的服務(wù)器程序.所以，你需要一種方法模仿服務(wù)器，這樣便可以編寫測試代碼了.
還有另外一種情況，假設(shè)你同其它開發(fā)者一起開發(fā)一個(gè)項(xiàng)目.你想測試項(xiàng)目中你的那一部分.但其中部分還沒有完成，那該怎么辦呢?解決的辦法是用一個(gè)仿造品模擬缺失的部分.
這里有兩個(gè)策略，供我們生成模擬對(duì)象:stub技術(shù)和使用mock objects. Stub是個(gè)原始的方法，但如今仍很流行，很大程度上是因?yàn)�，它們使得你可以測試代碼，而不必特意為了測試而修改代碼，Mock objects則是另外一種情況.在這章我們專門介紹stub技術(shù)，第7章講到mock objects.
6.1 stub簡介
Stub這種機(jī)制是用來模擬可能存在或還沒寫完的真實(shí)代碼所產(chǎn)生的行為.它使你能順利地測試系統(tǒng)的一部分，而無須考慮其他部分是否可行.通常，stub不會(huì)改變你測試的代碼，只是加以適配以提供無縫整合.
Stub----stub是代碼的一部分.在運(yùn)行時(shí)我們用stub替換真正代碼，忽略調(diào)用代碼的實(shí)現(xiàn).目的是用一個(gè)簡單一點(diǎn)的行為替換一個(gè)復(fù)雜的行為，從而允許獨(dú)立地測試代碼的某一部分.
這里有一些用到stub的例子:
你能不修改一個(gè)現(xiàn)有的系統(tǒng)，因?yàn)樗軓?fù)雜，很容易崩潰.
粗粒度測試，如在不同子系統(tǒng)之間進(jìn)行集成測試.
通常，stub給測試的系統(tǒng)以相當(dāng)好的可靠性.使用stub，你并沒有修改被測試的對(duì)象，你所測試的對(duì)象同將來產(chǎn)品中要運(yùn)行的一樣.用stub進(jìn)行測試一般是運(yùn)行環(huán)境中完成的.這保證了系統(tǒng)運(yùn)行的可靠性.
從另一面來說，stub通常難以編寫，尤其當(dāng)仿真系統(tǒng)很復(fù)雜的時(shí)候.stub需要實(shí)現(xiàn)和替代的代碼一樣的邏輯，而準(zhǔn)確地再現(xiàn)復(fù)雜邏輯是一件很困難的事.而結(jié)果常常是需要調(diào)試stub!下面列出了不使用stub的理由:
Stub常常會(huì)很復(fù)雜，它們本身需要調(diào)試.
因?yàn)閟tub的復(fù)雜性，它們可能會(huì)很難維護(hù)
Stub不能很好的運(yùn)用于細(xì)粒度測試.
不同的情況需要不同的策略.
一般而言，stub更適合代替代碼中粗粒度的部分.你通常會(huì)愿意用stub代替成熟的外部系統(tǒng)，諸如，文件系統(tǒng)，到服務(wù)器的連接，數(shù)據(jù)庫等.用stub替代對(duì)單一類的方法調(diào)用可以做到，但是比較難實(shí)現(xiàn).
6.2 一個(gè)HTTP連接的例子
為了演示stub能做些什么，我們?yōu)橐粋�(gè)簡單的程序創(chuàng)建了一些stub，它根據(jù)URL打開了一個(gè)http連接，同時(shí)讀取其中的信息.圖6.1顯示了一個(gè)程序例子，它通過HTTP連接遠(yuǎn)程web資源.
在這一章里我們的目標(biāo)是通過用stub替換遠(yuǎn)程web資源來對(duì)getContent方法執(zhí)行單元測試.
這種方法允許你獨(dú)立地測試執(zhí)行web資源的getContent方法.
關(guān)于stub重要的一點(diǎn)是，getContent沒有為接收stub而作修改.對(duì)于被測試的程序而言是透明的.為了實(shí)現(xiàn)這點(diǎn)，被替換的外圍代碼需要有定義完善的接口，并允許插入不同的實(shí)現(xiàn).
讓我們來以一個(gè)簡單HTTP連接的例子來看看stub是如何運(yùn)行的把.代碼6.1中的樣本程序給出了一個(gè)代碼片斷，它為給定的URL打開HTTP連接，讀取找到的URL上的信息.設(shè)想一下，這個(gè)方法是你想對(duì)其執(zhí)行單元測試的一個(gè)大項(xiàng)目的一部分.現(xiàn)在，讓我們對(duì)這個(gè)方法進(jìn)行單元測試吧.
6.2.1 選擇一個(gè)替換方案
在案例程序中有兩個(gè)可能的情況:遠(yuǎn)程web服務(wù)器位于開發(fā)平臺(tái)的外圍，或者，本身是程序配置平臺(tái)的一部分.不管怎樣，為了能夠?qū)ebClient類進(jìn)行單元測試，你必須在開發(fā)平臺(tái)上建立一個(gè)服務(wù)器.相對(duì)容易的解決辦法是為其安裝一個(gè)Apache測試服務(wù)器，在它的文檔根目錄下放一些測試web頁面.這是典型的，廣泛使用的替換方法.但它有缺陷:
依賴環(huán)境---在測試前確保運(yùn)行環(huán)境已經(jīng)準(zhǔn)備好了.如果web服務(wù)器關(guān)閉了，但測試被執(zhí)行了，結(jié)果必然是錯(cuò)誤的.那時(shí)你便會(huì)試著檢查出錯(cuò)的原因.接著，你發(fā)現(xiàn)代碼工作正常—這只是運(yùn)行環(huán)境的問題，導(dǎo)致一個(gè)錯(cuò)誤的警告.這種事情既浪費(fèi)時(shí)間又令人厭煩.所以，你在單元測試時(shí)，重要的一點(diǎn)是盡可能地控制測試執(zhí)行中的環(huán)境，這樣才能保證測試結(jié)果的可再現(xiàn)性.
分散的測試邏輯---測試邏輯被分散到兩個(gè)不同的地方:一是在Junit TestCase，二是測試web頁面.這兩種資源都需要在測試中保持同步.
測試難以實(shí)現(xiàn)自動(dòng)化—自動(dòng)執(zhí)行測試還是很困難，因?yàn)樗枰趙eb服務(wù)器上自動(dòng)配置web頁面，自動(dòng)啟動(dòng)web服務(wù)器，而完成這一切僅僅是為了運(yùn)行單元測試.
幸運(yùn)地，有一個(gè)更好的解決辦法---使用嵌入式服務(wù)器.你在java中進(jìn)行測試，所以容易的選擇是使用可以嵌入test
Case類的Java web服務(wù)器.確實(shí)存在這樣的好東西，它叫Jetty.
為什么是Jetty?因?yàn)樗休^快的運(yùn)行速度，它是輕量級(jí)的，而且在java中可以從test case中完全控制其運(yùn)行.另外，它還是一個(gè)很好的web/servlet容器，可以在產(chǎn)品中使用它.這對(duì)于測試而言不是特別重要，但是使用好的技術(shù)始終是一個(gè)好的策略.
使用Jetty能讓你消除前文提到的不足之處:服務(wù)器從Junit test case開始運(yùn)行，所有測試都在同一個(gè)位置用java編寫，把test suite自動(dòng)化也成了一個(gè)微不足道的問題.得益于Jetty的模塊性，要做的事情只是用stub替換Jetty處理器，而不是替換整個(gè)服務(wù)器.
6.2.2 用Jetty作為嵌入式服務(wù)器
為了更好地了解如何從測試中建立和控制Jetty，我們實(shí)現(xiàn)了一個(gè)從Java代碼中啟動(dòng)Jetty的簡單例子.代碼6.2演示如何從java中啟動(dòng)以及如何定義一個(gè)文檔根目錄(/)以啟動(dòng)服務(wù)文件.圖6.3說明了當(dāng)你運(yùn)行程序并在URL http://localhost:8080上打開瀏覽器的結(jié)果.
代碼6.2以嵌入模式啟動(dòng)Jetty――JettySample類
