3、Action层

　　action层的目的：对于请求进行跳转控制。

　　一个控制层方法的主要功能有：获取参数，调用BL对参数进行执行，根据执行的结果进行页面参数赋值，跳转到结果页面。

　　当然上面除了跳转的到结果页以外其他功能都不是必须的。

　　针对于上述功能action的单元测试基本框架是：封装请求参数，发送请求，判断所需的页面bean和跳转的结果页面是否正确。

　　这里牵扯到对于请求环境的模拟，一般不同的前台构架会有不同的模拟方法，struts下我使用的是strutstescase，它可以较为完整的读取Struts配置文件。

　　当然一般在action中会用到Spring的上下文获取bl，由于之前已经对bl进行了测试确认，所以我建议可以直接使用实际的bl，而不是再花费代价开发一个模拟的BL。

　　4、taglib层

　　taglib层目的：根据参数在页面上按照固定的样式输出。

　　一个标签的基本功能有：获取参数，调用BL对参数进行执行，把执行结果放到指定样式中，把得到的页面代码输出。

　　相对来说获取参数，调用BL对参数进行执行，把得到的页面代码输出，比较固定，测试的意义不大，所以主要测试的就是把执行结果放到指定样式中这个功能。这个功能通常就是给一个结果集参数然后组合返回一个StringBuffer，所以测试起来也比较容易。

　　但是taglib在使用的时候也需要的Spring甚至Struts的配置，这就需要在初始化的时候把相关环境也要加载进来。

　　这里大家因该可以看出我的单元测试并不是完全独立的，而是伴随渐进的按照DAO，BL，Action，taglib这样的顺序引入环境，这样一个可以减少测试开发的代价，一个是可以增加测试的准确性。

　　领域层

　　起初我们使用TDD的时候，从领域模型开始，两个人先在纸上画出领域模型的草图，写上一些显而易见的方法，然后打开Eclipse开始写JUnit单元测试，Eclipse对于TDD的支持很好，我们按照特性描述（就算是User Story吧），开始创建每个对象，当然会抱错，然后使用Eclipse自动创建那个类，我们会根据需求加入责任，然后自动生成method stub。我们花了两个小时创建了6个对象，完成了一个特性。当然，对于领域层的测试，这一切都很正常。

　　然后我们引入了Springframework，我们先设计一些接口，然后在Spring的配置文件中映射好实现这些接口的对象，然后我们在测试用例中写上spring初始化bean的代码：

　　java 代码

　　我们在每一个测试方法里都写，后来知道应该把这样的代码放到setUp中。我又开始使用Spring的测试框架，但是这样运行单元测试实在是太慢了！后来，知道了测试领域层的时候不要混入框架，创建对象直接用new就好。