6.3 替換web服務器資源
現在你知道如何簡單地啟動和配置Jetty了，下一步我們把視線放在HTTP連接的testcase上，你會先寫一個測試來證明可以調用一個有效的URL，并能取得它的內容。
6.3.1 建立第一個stub測試
為了證明webClient工作于有效的URL，你需要在測試前啟動Jetty服務器，這些你能在Junit test case里setUp方法中實現。你還可以用tearDown方法停止服務器的運行。代碼6.3列出了具體做法。
為了實現setUp和rearDown方法，你有兩條解決之道。準備一個包含文本“it works”的靜態頁面。把該文本放在你的文檔根目錄中。另一種方法是，配置Jetty以使用你自己定制的處理器，它不用在文件系統的文件中取字符串，而是直接返回一個字符串。這是一個更強大的技術，即便遠程http服務器在你的webclient客戶應用程序上拋出一個錯誤代碼的時候，你還是能對這個test case進行單元測試。
創建一個Jetty處理器
代碼6.4顯示了如何創建一個返回“it works”的jetty處理器。
每個test suite 啟動和停止jetty各一次
6.4 替換連接
現在，你替換了服務器的資源。改為http連接又會如何呢？這樣做會妨礙你有效的測試連接，但這沒有關系，這一點不正是你真正的目標
。你真正感興趣的是孤立地測試代碼邏輯。在以后的階段可以用功能測試或集成測試來檢驗連接。
當你需要不改變代碼替換連接的時候，你會發現自己很幸運，因為JDK的URL和HttpURLConnection類允許你引入自定義的協議處理器，處理任何類型的通訊協議。你可以使任何對HttpURLConnection類的調用指向你自己的測試類，這些類會返回測試中任何需要的東西。
6.4.1 創建自定義RUL協議處理器
為了實現自定義的URL協議處理器，你需要調用以下的JDK方法，并把它傳遞給自定義的URLStramHandlerFactory對象：
Java.net.setURLStreamHandlerFactory
第7章：用mock object孤立測試
孤立于其他方法和環境而單元測試每一個方法，這顯然是個值得追求的目標。但如何實現呢？在第六章中你知道了stub技術是怎樣把代碼和環境隔離起來而進行單元測試的。那么諸如隔離調用其他類的方法此類的細粒度隔離又如何呢？可行嗎？實現這些會不會需要付出很大的努力，從而抵消進行測試所帶來的收益？
回答是：“可以實現的”這項技術叫做mock objects。假設你要單元測試每一個方法，mock objects策略允許你在可能的細等級上進行單元測試，逐個方法地進行測試。
7.1 mock objects 簡介
隔離測試有著巨大的好處，如可以測試還未寫完的代碼，另外，隔離測試能幫助團隊單元測試代碼的一部分，而無需等待全部代碼的完成。
也許大的好處在于編寫專門測試單一方法的代碼，免去了被測試的方法調用其他對象而帶來的副作用。小是美。編寫小而專一的測試是有用的；小的測試容易理解，當代碼的其他部分改變時也不會被破壞。記住，進行成組測試的一個好處是，它給了你重構的勇氣――單元測試像反對衰退的衛士。如果你的測試粒度比較大，那么一旦重構引入了一個bug，會有一系列的測試失敗；結果是測試告訴你出現了一個錯誤，但你并不知道它在哪里。
Mock objects （簡稱mocks）非常適合把部分代碼邏輯的測試同其他的代碼隔離開來。Mocks替換了測試中你的方法協作的對象，從而提供了隔離層。從這個意義來說，它跟stub類似。
7.2 體驗mock objects ; 一個簡單例子
讓我們體驗一下第一個mock
7.3 把Mock objects 用作重構手法
有一些人曾經說過，單元測試應該對測試中的代碼透明；你不應為了簡化測試而改變運行時代碼。這是錯誤的！單元測試是對運行時代碼的好應用，應該同其他運用同等看待。如果你的代碼不能在測試中應用，你應該糾正代碼。
第8章: 使用Cactus進行容器內測試
本章內容
對組件進行單元測試時用mock objects的缺點
介紹使用Cactus進行容器內測試
Cactus的工作原理
在恰當的時候進行的設計，讓程序要么不能運行，一旦運行起來是正確運行
從本章開始，我們將研討如何對J2EE組件進行單元測試.對組件進行單元測試要難于對普通Java類進行單元測試.組件要和它們的容器打交道，而容器只有在運行時才能提供服務.Junit并沒有像其他J2EE組件那樣被設計成在容器內執行，那么我們該如何測試組件呢?
本章介紹了一種對J2EE組件進行單元測試的方法:容器內單元測試，也稱作集成單元測試.更確切地說，我們講討論使用cactus框架在容器內運行J2EE測試的好處和壞處.我們將展示，使用第7章介紹的mock objects方法能做到什么，而這種方法無能為力時容器內測試方法如何使得你可以編寫集成單元測試.
8.1 對組件進行單元測試的問題
想象一下，你有一個web應用程序，它使用了servlet，你希望對sampleservlet servlet的isAuthenticated 方法進行單元測試.
為了能夠測試這個方法，你需要得到一個合法的HttpServletRequest對象.不幸的是，不可能調用new HttpServletRequest 來創建一個可用的請求.HttpServletRequest 的生命周期是由容器管理的，無法單獨使用Junit為isAuthenticated 方法編寫測試.
定義: 組件/容器—組件是在容器內部執行的一段代碼.容器則是為存放在內的組件提供有用服務的器皿.
幸運的是，有幾種可供選擇的解決方案，我們將在后續的小節中談到這些方案.概括地說，我們將展現兩種核心方案:用mock objects進行容器外測試和用Cactus進行容器內測試
這兩種方法的一個變體是使用stub容器，比如HttpUnit中的ServletUnit模塊.不幸的是，我們沒有找到J2EE容器的完整stub實現.ServletUnit只實現了一部分Servlet規約
Mock objects和Cactus都是可行的方法.在第7章中，我們討論了mock objects這種容器外策略的優勢和劣勢.在本章中，我們將我們專注于Cactus這種容器內策略，并展示它的相對優勢和劣勢.第9章我們將專注于對servlet進行單元測試.在那一章中，我們將討論當測試servlet的時候何時使用mock objects，何時使用Cactus.
8.2 用mock objects測試組件
讓我們試著用mock objects來測試servlet，然后討論這種方法得優勢和劣勢.在第7章中，你創建了你自己得mock objects.幸運的是，有好幾個框架可以自動生成mock objects.在本章中，你將使用EasyMock(http://www.easymock.org)
