3.1.2 實現基類
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 增加處理器
測試來自何方?
為了創建一個單元測試，你需要兩種類型的對象:你需要測試的領域對象和同被測試的對象交互的測試對象
測試類存在于何方
你把測試類存放在何方?Java提供了幾種解決方案.
把它們作為package中的共有類
把它們作為test Case類的內部類
Junit佳實踐:選擇有意義的測試方法名
遵循的步驟有章可尋:
1. 在開始測試時把環境設置為已知狀態.測試前的狀態常稱為Test Fixture;
2. 調用待測試的方法;
3. 確認測試結果，這里通常是調用一個或多個Assert方法實現的;
3.2.3處理請求
Junit佳實踐:在assert中解釋失敗原因
分離出初始化邏輯
3.2.4 改進testProcessRequest
3.3 測試異常處理
Junit佳實踐:測試任何可能失敗的事物
3.3.1模擬異常條件
異常Test Case才是單元測試真正閃光的地方
3.4 建立測試項目
Junit佳實踐:同一個包，分離的目錄
第四章:探索軟件測試
崩潰指的是你的計算機程序的死亡，當你的程序死亡的時候，這是一個”特性”，
通常，緊跟崩潰之后的是一個像”ID 02”這樣的消息，”ID”是對特性的一個簡稱，而跟隨的消息
數目又指出了這個產品所再需要的測試的月數. ---------------Guy Kawasaki
在本書的前面幾章，給出了非常實際的設計和部署單元測試的指導.本章則后退一步.帶你從
更遠的地方領略軟件測試的各種各樣的類型，已經它們在應用生命周期中所扮演的角色.
本章告訴你如何為了可測試性而設計，以及怎樣實現測試先行的開發.
為什么你需要知道所有這些呢，因為進行單元測試不是件心血來潮的事情.為了成為一個
好的開發者，你必須理解為什么一定要做這件事，以及你為什么要寫單元測試而不是編寫功能測試，
集成測試和其他種類的測試.一旦你理解了你為什么要寫單元測試，你知道你應該進行多遠，何時你才
具備足夠的測試，測試不是一個終的目標.
后，我們將會向你展示測試驅動開發將會怎樣潛移默化地改善你的應用程序的性能和設計，
這是通過把單元測試放在開發過程的中心地位而做到的.
4.1 單元測試的必要性
功能測試也能夠做到這點，但是，單元測試是更強大和多方面的，它能夠做的不僅僅是簡單地驗證應用程序正常工作.
他還能:
帶來比功能測試更廣范圍的測試覆蓋.
讓團隊協作成為可能.
能夠防止衰退，降低調試的需要.
能為我們帶來重構的勇氣.
能改進實現設計.
當作開發文檔使用.
單元測試非常有趣.
4.1.1 帶來更大的測試范圍
功能測試應該是應用程序所應有的第一種測試類型.如果你必須在寫單元測試和功能測試之間做出選擇，
那么你應該選擇后者.在我們的經驗中，功能測試能發現70%的應用程序代碼錯誤.如果你希望進行更深入一點，想
提供更大測試覆蓋范圍，那么你需要寫單元測試了.
單元測試能夠很容易地模擬錯誤條件，這點在功能測試中很難辦到.盡管如此，若你使得要不要進行軟件測試
完全取決于測試覆蓋范圍，這也是一個錯誤，單元測試比單純地測試能提供更多東西，這將會在一下地小節中說到.
4.1.2 帶來團隊協作的可能
設想一下，你是一個團隊中的一員，在整個應用程序的某一個部分上工作.單元測試使你能夠遞交高質量代碼
而不需要等到其他部分都完成以后.另一方面，功能測試也更粗糙，而且需要整個應用程序完成之后才能進行測試.
4.1.3 防止衰退，減少調試
一組好的單元測試能夠給你帶來自信，讓你確信自己的代碼能很好的工作，它也給你去修改你現存的代碼的勇氣，
要么是重構的目的，要么是為了增加或是修改特性.作為一個開發者，沒有什么比這更好的感覺了;知道有人正站在你背后，
而且在你損壞一些東西的時候將會給你提醒.
一個必然的推論是:一組好的測試能減少用調試程序來發現錯誤的必要.
Junit佳實踐:重構
