3.1.2 實現(xiàn)基類

public class DefaultController implements Controller {
      private Map<String，RequestHandler> requestHandlers = new HashMap<String，RequestHandler>();

      protected RequestHandler getHandler(Request request){
            if(!requestHandlers.containsKey(request.getName())){
                  String message="Can't find handler for request name["+
                  request.getName()+"]";
                  throw new RuntimeException(message);
            }
            return (RequestHandler)this.requestHandlers.get(request.getName());         
      }
      public void addHandler(Request request， RequestHandler handler) {
            if (this.requestHandlers.containsKey(request.getName())){
                  String message="A handler has already been registered for request name["+
                        request.getName()+"]";
                  throw new RuntimeException(message);
            }else{
                  requestHandlers.put(request.getName()， handler);
            }
                
      }

      public Response processRequest(Request request) {
            Response response;
            try{
                  response = getHandler(request).process(request);
            }
            catch(Exception ex){
                  response = new ErrorResponse(request，ex);
                
                
            }
            return response;
      }
    

}

3.2讓我們來測試吧
3.2.1 測試DefaultController

3.2.2 增加處理器
測試來自何方?
為了創(chuàng)建一個單元測試，你需要兩種類型的對象:你需要測試的領域對象和同被測試的對象交互的測試對象

測試類存在于何方
你把測試類存放在何方?Java提供了幾種解決方案.
  把它們作為package中的共有類
  把它們作為test Case類的內部類

Junit佳實踐:選擇有意義的測試方法名

遵循的步驟有章可尋:
1. 在開始測試時把環(huán)境設置為已知狀態(tài).測試前的狀態(tài)常稱為Test Fixture;
2. 調用待測試的方法;
3. 確認測試結果，這里通常是調用一個或多個Assert方法實現(xiàn)的;
3.2.3處理請求
Junit佳實踐:在assert中解釋失敗原因
分離出初始化邏輯

3.2.4 改進testProcessRequest

3.3 測試異常處理
Junit佳實踐:測試任何可能失敗的事物
3.3.1模擬異常條件
      異常Test Case才是單元測試真正閃光的地方

3.4 建立測試項目
Junit佳實踐:同一個包，分離的目錄

第四章:探索軟件測試
                崩潰指的是你的計算機程序的死亡，當你的程序死亡的時候，這是一個”特性”，
通常，緊跟崩潰之后的是一個像”ID 02”這樣的消息，”ID”是對特性的一個簡稱，而跟隨的消息
數(shù)目又指出了這個產品所再需要的測試的月數(shù).                                ---------------Guy Kawasaki

在本書的前面幾章，給出了非常實際的設計和部署單元測試的指導.本章則后退一步.帶你從
更遠的地方領略軟件測試的各種各樣的類型，已經(jīng)它們在應用生命周期中所扮演的角色.
本章告訴你如何為了可測試性而設計，以及怎樣實現(xiàn)測試先行的開發(fā).
                為什么你需要知道所有這些呢，因為進行單元測試不是件心血來潮的事情.為了成為一個
好的開發(fā)者，你必須理解為什么一定要做這件事，以及你為什么要寫單元測試而不是編寫功能測試，
集成測試和其他種類的測試.一旦你理解了你為什么要寫單元測試，你知道你應該進行多遠，何時你才
具備足夠的測試，測試不是一個終的目標.
                后，我們將會向你展示測試驅動開發(fā)將會怎樣潛移默化地改善你的應用程序的性能和設計，
這是通過把單元測試放在開發(fā)過程的中心地位而做到的.
4.1 單元測試的必要性
                功能測試也能夠做到這點，但是，單元測試是更強大和多方面的，它能夠做的不僅僅是簡單地驗證應用程序正常工作.
他還能:
                帶來比功能測試更廣范圍的測試覆蓋.
                讓團隊協(xié)作成為可能.
                能夠防止衰退，降低調試的需要.
                能為我們帶來重構的勇氣.
                能改進實現(xiàn)設計.
                當作開發(fā)文檔使用.
                單元測試非常有趣.
4.1.1 帶來更大的測試范圍
                功能測試應該是應用程序所應有的第一種測試類型.如果你必須在寫單元測試和功能測試之間做出選擇，
那么你應該選擇后者.在我們的經(jīng)驗中，功能測試能發(fā)現(xiàn)70%的應用程序代碼錯誤.如果你希望進行更深入一點，想
提供更大測試覆蓋范圍，那么你需要寫單元測試了.
                單元測試能夠很容易地模擬錯誤條件，這點在功能測試中很難辦到.盡管如此，若你使得要不要進行軟件測試
完全取決于測試覆蓋范圍，這也是一個錯誤，單元測試比單純地測試能提供更多東西，這將會在一下地小節(jié)中說到.
4.1.2 帶來團隊協(xié)作的可能
                設想一下，你是一個團隊中的一員，在整個應用程序的某一個部分上工作.單元測試使你能夠遞交高質量代碼
而不需要等到其他部分都完成以后.另一方面，功能測試也更粗糙，而且需要整個應用程序完成之后才能進行測試.
4.1.3 防止衰退，減少調試
                一組好的單元測試能夠給你帶來自信，讓你確信自己的代碼能很好的工作，它也給你去修改你現(xiàn)存的代碼的勇氣，
要么是重構的目的，要么是為了增加或是修改特性.作為一個開發(fā)者，沒有什么比這更好的感覺了;知道有人正站在你背后，
而且在你損壞一些東西的時候將會給你提醒.
                一個必然的推論是:一組好的測試能減少用調試程序來發(fā)現(xiàn)錯誤的必要.

Junit佳實踐:重構