6.3 替換web服務器資源
         現(xiàn)在你知道如何簡單地啟動和配置Jetty了，下一步我們把視線放在HTTP連接的testcase上，你會先寫一個測試來證明可以調(diào)用一個有效的URL，并能取得它的內(nèi)容。

6.3.1 建立第一個stub測試
         為了證明webClient工作于有效的URL，你需要在測試前啟動Jetty服務器，這些你能在Junit test case里setUp方法中實現(xiàn)。你還可以用tearDown方法停止服務器的運行。代碼6.3列出了具體做法。
         為了實現(xiàn)setUp和rearDown方法，你有兩條解決之道。準備一個包含文本“it works”的靜態(tài)頁面。把該文本放在你的文檔根目錄中。另一種方法是，配置Jetty以使用你自己定制的處理器，它不用在文件系統(tǒng)的文件中取字符串，而是直接返回一個字符串。這是一個更強大的技術(shù)，即便遠程http服務器在你的webclient客戶應用程序上拋出一個錯誤代碼的時候，你還是能對這個test case進行單元測試。
         創(chuàng)建一個Jetty處理器
         代碼6.4顯示了如何創(chuàng)建一個返回“it works”的jetty處理器。
每個test suite 啟動和停止jetty各一次
       
       
6.4 替換連接
         現(xiàn)在，你替換了服務器的資源。改為http連接又會如何呢？這樣做會妨礙你有效的測試連接，但這沒有關(guān)系，這一點不正是你真正的目標
。你真正感興趣的是孤立地測試代碼邏輯。在以后的階段可以用功能測試或集成測試來檢驗連接。
         當你需要不改變代碼替換連接的時候，你會發(fā)現(xiàn)自己很幸運，因為JDK的URL和HttpURLConnection類允許你引入自定義的協(xié)議處理器，處理任何類型的通訊協(xié)議。你可以使任何對HttpURLConnection類的調(diào)用指向你自己的測試類，這些類會返回測試中任何需要的東西。
       
6.4.1 創(chuàng)建自定義RUL協(xié)議處理器
         為了實現(xiàn)自定義的URL協(xié)議處理器，你需要調(diào)用以下的JDK方法，并把它傳遞給自定義的URLStramHandlerFactory對象：
Java.net.setURLStreamHandlerFactory

第7章：用mock object孤立測試
         孤立于其他方法和環(huán)境而單元測試每一個方法，這顯然是個值得追求的目標。但如何實現(xiàn)呢？在第六章中你知道了stub技術(shù)是怎樣把代碼和環(huán)境隔離起來而進行單元測試的。那么諸如隔離調(diào)用其他類的方法此類的細粒度隔離又如何呢？可行嗎？實現(xiàn)這些會不會需要付出很大的努力，從而抵消進行測試所帶來的收益？
         回答是：“可以實現(xiàn)的”這項技術(shù)叫做mock objects。假設你要單元測試每一個方法，mock objects策略允許你在可能的細等級上進行單元測試，逐個方法地進行測試。
7.1 mock objects 簡介
         隔離測試有著巨大的好處，如可以測試還未寫完的代碼，另外，隔離測試能幫助團隊單元測試代碼的一部分，而無需等待全部代碼的完成。
         也許大的好處在于編寫專門測試單一方法的代碼，免去了被測試的方法調(diào)用其他對象而帶來的副作用。小是美。編寫小而專一的測試是有用的；小的測試容易理解，當代碼的其他部分改變時也不會被破壞。記住，進行成組測試的一個好處是，它給了你重構(gòu)的勇氣――單元測試像反對衰退的衛(wèi)士。如果你的測試粒度比較大，那么一旦重構(gòu)引入了一個bug，會有一系列的測試失�。唤Y(jié)果是測試告訴你出現(xiàn)了一個錯誤，但你并不知道它在哪里。
         Mock objects （簡稱mocks）非常適合把部分代碼邏輯的測試同其他的代碼隔離開來。Mocks替換了測試中你的方法協(xié)作的對象，從而提供了隔離層。從這個意義來說，它跟stub類似。
7.2 體驗mock objects ; 一個簡單例子
         讓我們體驗一下第一個mock

7.3 把Mock objects 用作重構(gòu)手法
         有一些人曾經(jīng)說過，單元測試應該對測試中的代碼透明；你不應為了簡化測試而改變運行時代碼。這是錯誤的！單元測試是對運行時代碼的好應用，應該同其他運用同等看待。如果你的代碼不能在測試中應用，你應該糾正代碼。

第8章: 使用Cactus進行容器內(nèi)測試
本章內(nèi)容
                對組件進行單元測試時用mock objects的缺點
                介紹使用Cactus進行容器內(nèi)測試
                Cactus的工作原理
在恰當?shù)臅r候進行的設計，讓程序要么不能運行，一旦運行起來是正確運行
                從本章開始，我們將研討如何對J2EE組件進行單元測試.對組件進行單元測試要難于對普通Java類進行單元測試.組件要和它們的容器打交道，而容器只有在運行時才能提供服務.Junit并沒有像其他J2EE組件那樣被設計成在容器內(nèi)執(zhí)行，那么我們該如何測試組件呢?
                本章介紹了一種對J2EE組件進行單元測試的方法:容器內(nèi)單元測試，也稱作集成單元測試.更確切地說，我們講討論使用cactus框架在容器內(nèi)運行J2EE測試的好處和壞處.我們將展示，使用第7章介紹的mock objects方法能做到什么，而這種方法無能為力時容器內(nèi)測試方法如何使得你可以編寫集成單元測試.
8.1 對組件進行單元測試的問題
                想象一下，你有一個web應用程序，它使用了servlet，你希望對sampleservlet servlet的isAuthenticated 方法進行單元測試.
為了能夠測試這個方法，你需要得到一個合法的HttpServletRequest對象.不幸的是，不可能調(diào)用new HttpServletRequest 來創(chuàng)建一個可用的請求.HttpServletRequest 的生命周期是由容器管理的，無法單獨使用Junit為isAuthenticated 方法編寫測試.
定義: 組件/容器—組件是在容器內(nèi)部執(zhí)行的一段代碼.容器則是為存放在內(nèi)的組件提供有用服務的器皿.
                幸運的是，有幾種可供選擇的解決方案，我們將在后續(xù)的小節(jié)中談到這些方案.概括地說，我們將展現(xiàn)兩種核心方案:用mock objects進行容器外測試和用Cactus進行容器內(nèi)測試
                這兩種方法的一個變體是使用stub容器，比如HttpUnit中的ServletUnit模塊.不幸的是，我們沒有找到J2EE容器的完整stub實現(xiàn).ServletUnit只實現(xiàn)了一部分Servlet規(guī)約
                Mock objects和Cactus都是可行的方法.在第7章中，我們討論了mock objects這種容器外策略的優(yōu)勢和劣勢.在本章中，我們將我們專注于Cactus這種容器內(nèi)策略，并展示它的相對優(yōu)勢和劣勢.第9章我們將專注于對servlet進行單元測試.在那一章中，我們將討論當測試servlet的時候何時使用mock objects，何時使用Cactus.

8.2 用mock objects測試組件
                讓我們試著用mock objects來測試servlet，然后討論這種方法得優(yōu)勢和劣勢.在第7章中，你創(chuàng)建了你自己得mock objects.幸運的是，有好幾個框架可以自動生成mock objects.在本章中，你將使用EasyMock(http://www.easymock.org)