通常我们的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出来，但是我一般觉得这种模拟花消比较大，这个代价是否值得一直是我所怀疑的。