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佳实践:重构
