通常我们的bs模式应同都是5层构架体系的：DAO BL Action Taglib JSP
在这5层之中，只有jsp是非java代码的，所以也是比较难以进行单元测试的一层
而且jsp作为表现层来说呢，通常变化也比较大。所以对jsp编写代码测试的代价要远大于人工直接对页面样式进行测试。
这篇文章主要将针对除去jsp以外的另外4层相关单元测试的基本框架进行了一些讨论：
首先我们要在单元测试前问自己一个问题：单元测试的目的究竟是为了什么？
为了让我们的项目更加时髦？为了让我写的代码没有bug？
我个人觉得单元测试的目的就是为了能够用轻易的重复对代码的测试！
下面我将对每一层的目的是什么，单元测试的目的是什么，还有改层单元测试的相关问题进行讲述
1、DAO层
DAO的目的：根据指定的参数对相关的数据对象进行处理
基本操作有查询操作 对数据源无影响 有返回值
增改操作 影响数据源 无返回值
删除操作 影响数据源 无返回值
从上面我们可以看出，DAO的test主要是针对DAO的3种操作进行测试
对于查询操作我们可以从返回的结果集来进行判断
而对于增改操作和删除操作我们就是只能在方法调用后对数据源进行判断了
这里，现在一般DAO层我们都会使用Spring+hibernate来进行构建，那么一个DAO的实例就需要引入到spring和DAO的相关配置了。而且由于牵扯到外部环境，所以这里外部环境的处理可以采用两种方式，一种是直接使用数据库，这里就需要有一个真实的数据源存在了 二是模拟一个数据源，比如使用内存数据库或者文本数据库来建立一个模拟环境，方便单机进行测试
而且由于DAO是由Spring来进行管理的，所以在测试的时候需要加载Spring的上下文来获取dao的bean，关于spring的加载我使用的是spring-mock，它的好处是在事物处理后可以对相关的数据库操作进行rollback
2、BL层
BL层的目的：根据业务逻辑对业务处理进行封装
以往其实我们有时候习惯把一些业务逻辑代码放置到上层DAO或者下层Action，taglib中
所以我总结了一下，基本的业务逻辑有：
参数的验证和判断
业务逻辑错误处理
业务规则判断
所以针对于这些功能我们可以把原本属于BL的代码归还给BL了，然后针对于bl的几个功能就可以清晰地编写单元测试了，这时候一般会用到做单元测试时比较有用的一个副产品：重构。而这个副产品的价值将会在你重构后体现出来，DAO，BL，ACTION，taglib的代码职责更加明晰了，该做什么判断的就座什么判断
BL这层一般也是用Spring来进行管理的，所以我们还是需要加载spring的上下文，当然也可以不加载Spring，然后根据接口模拟一个DAO出来，但是我一般觉得这种模拟花消比较大，这个代价是否值得一直是我所怀疑的
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这样的顺序引入环境，这样一个可以减少测试开发的代价，一个是可以增加测试的准确性
在上面的描述中我们基本上了解了4层单元测试的基本目的和结构
下一篇文章中我会针对各个层的具体测试方法是用代码进行讲解 ：）