Dao层的测试实践

　　是Spring上下文加载后的变量。上面的@ SpringApplicationContext是指明要加载的Spring配置文件到一个变量，可以通过一个String数组和通配符加载多个配置，可以看到这里我们把common和测试数据源的testDatasource.xml都加载了。如果一个工程中，可以抽象出一个公用的测试基类，将Spring的上下文保存在基类中。

　　private AccountDao accountDao;

　　是我们要测试的目标对象，这里需要在前面加上@SpringBeanByType的标注，这样Unitils会自动根据类型，将目标对象从Spring上下文取出，注入到测试代码中。

　　public void testUpdateAccount ()

　　是测试插入的方法，其上的 @DataSet("ACCOUNT.xml")

　　指的是插入前的预制数据，Unitils和Dbunit会在执行该方法前，将EMPTY_TABLE.xml中的数据导入到数据库中，下面给出的是一个样例数据的xml。执行前，Unitils会清空该表，然后插入指定的测试数据。注：由于事务后回滚，清空的动作不会提交，所以不用担心数据的损失。

　　Xml代码

<?xml version='1.0' encoding='UTF-8'?>
<dataset>
  <tb_account account_id="S31993k" balance="100"/>
 </dataset>

　　@ExpectedDataSet("ACCOUNT_NEW.xml")

　　为执行测试用例后的期望数据，Unitils会比较实际结果和期望值，看看是否一致。如果不一致则抛出测试失败。ACCOUNT_NEW.xml的内容如下

　　Xml代码

<?xml version='1.0' encoding='UTF-8'?>
<dataset>
  <tb_account account_id="S31993k" balance="35"/>
 </dataset>

　　public void testGetAccount（）是查询一个已经存在的帐户。后通过断言查询是否存在编号为“S31993k”。注：每次执行一个用例方法的时候，DBUnit都会重新初始化相关的数据表，所以不用担心前面的测试用例操作会影响当前的用例结果

　　public void testGetAccountNull

　　这是一个尝试查询一个不存在的帐户信息，后Dao应该返回的是Null，这里用断言做了判断。

　　3、经验总结

　　Unitils通过整合Dbunit和Spring，让我们单元测试的工作量小而效果好。

　　下面是做Dao单元测试的经验

　　1）尽量让单元测试的数据库和其他测试的数据库分离开，避免相互影响。如果每个开发人员拥有自己的单元测试库那是好的。

　　2）Dbunit需要的数据集可以预先从数据库生成，而后面的测试可以重复利用这些数据集。数据集尽量小，保证只包含影响测试的数据。

　　3）数据库的外键是单元测试的障碍，建议去掉外键。数据的完整性应该靠应用程序保证。

　　4）没有断言不能称作单元测试，单元测试一定要自动化，而不是靠人眼判断。

　　5）如果Dao的单元测试会涉及到多个表（这种情况比较罕见），可以在一个xml中放置多个表的数据，Dbunit会自动识别导入到不同的表中。