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