第六章:用stub進行粗粒度測試
本章內(nèi)容:
                介紹stub
                使用嵌入式服務(wù)器代替真正的網(wǎng)絡(luò)服務(wù)器
                用stub單元測試一個HTTP連接案例
              
當你開發(fā)自己的應(yīng)用程序時，你可能會發(fā)現(xiàn)你想要測試的代碼段依賴于其它的類，而它們本身也依賴于另一些類，這些類則要依賴于開發(fā)環(huán)境.
                由于程序依賴于開發(fā)環(huán)境，編寫單元測試成為了一個挑戰(zhàn).你所做的測試需要具有穩(wěn)定性，當你一遍又一遍地運行它們，產(chǎn)生的結(jié)果必須是一致的.所以，你需要找到一個方法來控制運行環(huán)境.一個解決的辦法是建立真正的需求環(huán)境作為測試的一部分，并在其中運行測試.在某些情況下，這種方法是可行的，同時帶來了額外的價值.但是，只有你在開發(fā)平臺上建立真實環(huán)境，測試才工作得好.事實上，這種情況不是總是會出現(xiàn)的.
                例如，你的應(yīng)用程序使用http連接由第三方提供web服務(wù)器，但是在你的開發(fā)環(huán)境里通常并不存在那樣一個可用的服務(wù)器程序.所以，你需要一種方法模仿服務(wù)器，這樣便可以編寫測試代碼了.
                還有另外一種情況，假設(shè)你同其它開發(fā)者一起開發(fā)一個項目.你想測試項目中你的那一部分.但其中部分還沒有完成，那該怎么辦呢?解決的辦法是用一個仿造品模擬缺失的部分.
                這里有兩個策略，供我們生成模擬對象:stub技術(shù)和使用mock objects. Stub是個原始的方法，但如今仍很流行，很大程度上是因為，它們使得你可以測試代碼，而不必特意為了測試而修改代碼，Mock objects則是另外一種情況.在這章我們專門介紹stub技術(shù)，第7章講到mock objects.
6.1 stub簡介
                Stub這種機制是用來模擬可能存在或還沒寫完的真實代碼所產(chǎn)生的行為.它使你能順利地測試系統(tǒng)的一部分，而無須考慮其他部分是否可行.通常，stub不會改變你測試的代碼，只是加以適配以提供無縫整合.
                Stub----stub是代碼的一部分.在運行時我們用stub替換真正代碼，忽略調(diào)用代碼的實現(xiàn).目的是用一個簡單一點的行為替換一個復(fù)雜的行為，從而允許獨立地測試代碼的某一部分.
這里有一些用到stub的例子:
                你能不修改一個現(xiàn)有的系統(tǒng)，因為它很復(fù)雜，很容易崩潰.
                粗粒度測試，如在不同子系統(tǒng)之間進行集成測試.
              
通常，stub給測試的系統(tǒng)以相當好的可靠性.使用stub，你并沒有修改被測試的對象，你所測試的對象同將來產(chǎn)品中要運行的一樣.用stub進行測試一般是運行環(huán)境中完成的.這保證了系統(tǒng)運行的可靠性.
                從另一面來說，stub通常難以編寫，尤其當仿真系統(tǒng)很復(fù)雜的時候.stub需要實現(xiàn)和替代的代碼一樣的邏輯，而準確地再現(xiàn)復(fù)雜邏輯是一件很困難的事.而結(jié)果常常是需要調(diào)試stub!下面列出了不使用stub的理由:
                Stub常常會很復(fù)雜，它們本身需要調(diào)試.
                因為stub的復(fù)雜性，它們可能會很難維護
                Stub不能很好的運用于細粒度測試.
                不同的情況需要不同的策略.
                一般而言，stub更適合代替代碼中粗粒度的部分.你通常會愿意用stub代替成熟的外部系統(tǒng)，諸如，文件系統(tǒng)，到服務(wù)器的連接，數(shù)據(jù)庫等.用stub替代對單一類的方法調(diào)用可以做到，但是比較難實現(xiàn).
6.2          一個HTTP連接的例子
                為了演示stub能做些什么，我們?yōu)橐粋�簡單的程序創(chuàng)建了一些stub，它根據(jù)URL打開了一個http連接，同時讀取其中的信息.圖6.1顯示了一個程序例子，它通過HTTP連接遠程web資源.
                在這一章里我們的目標是通過用stub替換遠程web資源來對getContent方法執(zhí)行單元測試.
                這種方法允許你獨立地測試執(zhí)行web資源的getContent方法.
                關(guān)于stub重要的一點是，getContent沒有為接收stub而作修改.對于被測試的程序而言是透明的.為了實現(xiàn)這點，被替換的外圍代碼需要有定義完善的接口，并允許插入不同的實現(xiàn).
                讓我們來以一個簡單HTTP連接的例子來看看stub是如何運行的把.代碼6.1中的樣本程序給出了一個代碼片斷，它為給定的URL打開HTTP連接，讀取找到的URL上的信息.設(shè)想一下，這個方法是你想對其執(zhí)行單元測試的一個大項目的一部分.現(xiàn)在，讓我們對這個方法進行單元測試吧.

6.2.1 選擇一個替換方案
                在案例程序中有兩個可能的情況:遠程web服務(wù)器位于開發(fā)平臺的外圍，或者，本身是程序配置平臺的一部分.不管怎樣，為了能夠?qū)�webClient類進行單元測試，你必須在開發(fā)平臺上建立一個服務(wù)器.相對容易的解決辦法是為其安裝一個Apache測試服務(wù)器，在它的文檔根目錄下放一些測試web頁面.這是典型的，廣泛使用的替換方法.但它有缺陷:
                依賴環(huán)境---在測試前確保運行環(huán)境已經(jīng)準備好了.如果web服務(wù)器關(guān)閉了，但測試被執(zhí)行了，結(jié)果必然是錯誤的.那時你便會試著檢查出錯的原因.接著，你發(fā)現(xiàn)代碼工作正常—這只是運行環(huán)境的問題，導(dǎo)致一個錯誤的警告.這種事情既浪費時間又令人厭煩.所以，你在單元測試時，重要的一點是盡可能地控制測試執(zhí)行中的環(huán)境，這樣才能保證測試結(jié)果的可再現(xiàn)性.
                分散的測試邏輯---測試邏輯被分散到兩個不同的地方:一是在Junit TestCase，二是測試web頁面.這兩種資源都需要在測試中保持同步.
                測試難以實現(xiàn)自動化—自動執(zhí)行測試還是很困難，因為它需要在web服務(wù)器上自動配置web頁面，自動啟動web服務(wù)器，而完成這一切僅僅是為了運行單元測試.
              
                幸運地，有一個更好的解決辦法---使用嵌入式服務(wù)器.你在java中進行測試，所以容易的選擇是使用可以嵌入test
Case類的Java web服務(wù)器.確實存在這樣的好東西，它叫Jetty.
                為什么是Jetty?因為它有較快的運行速度，它是輕量級的，而且在java中可以從test case中完全控制其運行.另外，它還是一個很好的web/servlet容器，可以在產(chǎn)品中使用它.這對于測試而言不是特別重要，但是使用好的技術(shù)始終是一個好的策略.
                使用Jetty能讓你消除前文提到的不足之處:服務(wù)器從Junit test case開始運行，所有測試都在同一個位置用java編寫，把test suite自動化也成了一個微不足道的問題.得益于Jetty的模塊性，要做的事情只是用stub替換Jetty處理器，而不是替換整個服務(wù)器.
6.2.2 用Jetty作為嵌入式服務(wù)器
                為了更好地了解如何從測試中建立和控制Jetty，我們實現(xiàn)了一個從Java代碼中啟動Jetty的簡單例子.代碼6.2演示如何從java中啟動以及如何定義一個文檔根目錄(/)以啟動服務(wù)文件.圖6.3說明了當你運行程序并在URL http://localhost:8080上打開瀏覽器的結(jié)果.

代碼6.2以嵌入模式啟動Jetty――JettySample類