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)建一個單元測試，你需要兩種類型的對象:你需要測試的領域?qū)ο蠛屯粶y試的對象交互的測試對象
測試類存在于何方
你把測試類存放在何方?Java提供了幾種解決方案.
把它們作為package中的共有類
把它們作為test Case類的內(nèi)部類
Junit佳實踐:選擇有意義的測試方法名
遵循的步驟有章可尋:
1. 在開始測試時把環(huán)境設置為已知狀態(tài).測試前的狀態(tài)常稱為Test Fixture;
2. 調(diào)用待測試的方法;
3. 確認測試結(jié)果，這里通常是調(diào)用一個或多個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ù)目又指出了這個產(chǎn)品所再需要的測試的月數(shù). ---------------Guy Kawasaki
在本書的前面幾章，給出了非常實際的設計和部署單元測試的指導.本章則后退一步.帶你從
更遠的地方領略軟件測試的各種各樣的類型，已經(jīng)它們在應用生命周期中所扮演的角色.
本章告訴你如何為了可測試性而設計，以及怎樣實現(xiàn)測試先行的開發(fā).
為什么你需要知道所有這些呢，因為進行單元測試不是件心血來潮的事情.為了成為一個
好的開發(fā)者，你必須理解為什么一定要做這件事，以及你為什么要寫單元測試而不是編寫功能測試，
集成測試和其他種類的測試.一旦你理解了你為什么要寫單元測試，你知道你應該進行多遠，何時你才
具備足夠的測試，測試不是一個終的目標.
后，我們將會向你展示測試驅(qū)動開發(fā)將會怎樣潛移默化地改善你的應用程序的性能和設計，
這是通過把單元測試放在開發(fā)過程的中心地位而做到的.
4.1 單元測試的必要性
功能測試也能夠做到這點，但是，單元測試是更強大和多方面的，它能夠做的不僅僅是簡單地驗證應用程序正常工作.
他還能:
帶來比功能測試更廣范圍的測試覆蓋.
讓團隊協(xié)作成為可能.
能夠防止衰退，降低調(diào)試的需要.
能為我們帶來重構(gòu)的勇氣.
能改進實現(xiàn)設計.
當作開發(fā)文檔使用.
單元測試非常有趣.
4.1.1 帶來更大的測試范圍
功能測試應該是應用程序所應有的第一種測試類型.如果你必須在寫單元測試和功能測試之間做出選擇，
那么你應該選擇后者.在我們的經(jīng)驗中，功能測試能發(fā)現(xiàn)70%的應用程序代碼錯誤.如果你希望進行更深入一點，想
提供更大測試覆蓋范圍，那么你需要寫單元測試了.
單元測試能夠很容易地模擬錯誤條件，這點在功能測試中很難辦到.盡管如此，若你使得要不要進行軟件測試
完全取決于測試覆蓋范圍，這也是一個錯誤，單元測試比單純地測試能提供更多東西，這將會在一下地小節(jié)中說到.
4.1.2 帶來團隊協(xié)作的可能
設想一下，你是一個團隊中的一員，在整個應用程序的某一個部分上工作.單元測試使你能夠遞交高質(zhì)量代碼
而不需要等到其他部分都完成以后.另一方面，功能測試也更粗糙，而且需要整個應用程序完成之后才能進行測試.
4.1.3 防止衰退，減少調(diào)試
一組好的單元測試能夠給你帶來自信，讓你確信自己的代碼能很好的工作，它也給你去修改你現(xiàn)存的代碼的勇氣，
要么是重構(gòu)的目的，要么是為了增加或是修改特性.作為一個開發(fā)者，沒有什么比這更好的感覺了;知道有人正站在你背后，
而且在你損壞一些東西的時候?qū)o你提醒.
一個必然的推論是:一組好的測試能減少用調(diào)試程序來發(fā)現(xiàn)錯誤的必要.
Junit佳實踐:重構(gòu)
