论坛首页 → 综合技术论坛 →

单元测试之实践二,关于DAO的测试

浏览 16660 次
锁定老帖子 主题： 单元测试之实践二,关于DAO的测试
精华帖 (1) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
  • wuhua
  • 等级: 三钻会员
  • 性别:
  • 文章: 634
  • 积分: 1688
  • 来自: 广州
   发表时间：2006-12-11  
       前阵子发表过 我的第一个真正意义上的测试 。
里面对于测试Service大家是没有意义的，对于测试DAO层则表现各有各的看法。
比如
robbin     大哥建议：

测试DAO不如连数据库一起测试吧。因为DAO测试的目的不是DAO接口实现对不对，而是测试是否如你预期的发送了SQL，如你预期的返回了结果集。这个时候你Mock之后，测试就没有意义了。

hyysguyang      大哥建议：篇
wuhua 写道
分层的原因很多。这里我的看法片面就不说了
但对于mock来说是有莫大好处的。
比如service测试的时候完全可以做到隔离数据库，

我现在的意思是，
居然Service可以隔离Dao层，也就是说Dao层也是可以做到隔离相关的数据实现的。也是可以mock一个对象。而并非用实际的连接去代 替。如果我们的逻辑没出错的话，测试就算通过了，至于数据层的检测，那就不关我们的事情了，比如Hibernate由Hibernate去test， Spring由Spring去Test，Oracle由它自己去做。干自己的事情，别趟其他浑水。这样不是潇洒很多吗

但是数据库的测试毕竟比较特殊，记住测试的目的是确保你的代码质量，如果你确定你的这样测就没问题了，那无话可说，否则就尽量多的测试。
事实上，最原始的单元测试（plain testcase）就是用来测方法，测业务逻辑的，如果有逻辑就测，没逻辑就不用测了，同样的道理，相信你不会去测一个bean的get/set方法吧。
记住你测试的目的和动机，如果你认为测试dao层是为了测你的逻辑（你确定你的dao的实现代码是否真的存在逻辑），那你就mock吧，但是，我 们更相信，我们测DAO层，更应该是测访问数据库的情况，你如连接，sql是否正确，sequence是否正确等，而这些你必须要真正的连接数据库，也因 此，我们一般都是直接访问数据库来测试的，当然，如果可能你可以采用内存库。
事实上，我们对dao的测试，一般都进行所谓的的集成单元测试。我认为，你应该确定好你的测试策略，然后在去采用相应的测试方法。我在目前的开发中就是采用这样的方式测的。

上面两个大哥都建议测试DAO的时候还是连接数据库为好。
但个人认为上面两个大哥的单元测试以非纯正的单元测试了，而是集成单元测试。
其实说白了，测试这东西只是为了项目更好，更快的完成。至于是否要求纯单元，或者是集成单元测试，则看各位的需要，如果觉得集成单元测试对项目有帮助，那就用吧，现在发现对这个已经没有明显的界限了。


不理会它了，现在回归到我们用户注册的例子。
java 代码
 
  1. 1. public interface IAccountDao extends IBaseDao {    
  2. 2.     public Account findAccountById(String id);    
  3. 3.     public Account findAccounByName(String name);    
  4. 4. }   

实际实现代码
java 代码
 
  1. package org.wuhua.dao.impl;  
  2.   
  3. import java.util.List;  
  4.   
  5. import org.wuhua.dao.IAccountDao;  
  6. import org.wuhua.model.Account;  
  7.   
  8. public class AccountDao extends BaseDao implements IAccountDao {  
  9.   public Account findAccountById(String id) {  
  10.         return (Account) this.getHibernateTemplate().get(Account.class, id) ;  
  11.     }  
  12.   
  13.     public Account findAccounByName(String name) {  
  14.         List l = this.getHibernateTemplate().find("from Account as a where a.name=?", name);  
  15.         if(l != null && l.size() >=1)  
  16.             return (Account) l.get(0);  
  17.         else   
  18.             return null;  
  19.     }  
  20. }  

java 代码
 
  1. package org.wuhua.dao;  
  2.   
  3. import java.util.ArrayList;  
  4. import java.util.List;  
  5.   
  6. import junit.framework.Assert;  
  7. import junit.framework.TestCase;  
  8.   
  9. import org.easymock.MockControl;  
  10. import org.easymock.classextension.MockClassControl;  
  11. import org.springframework.orm.hibernate3.HibernateTemplate;  
  12. import org.wuhua.dao.impl.AccountDao;  
  13. import org.wuhua.model.Account;  
  14.   
  15.    
  16.   
  17. public class AccountDaoTest extends TestCase {  
  18.       
  19.     private AccountDao accountDao;  
  20.     private org.springframework.orm.hibernate3.HibernateTemplate ht;  
  21.     private MockControl control;  
  22.   
  23.     protected void setUp() throws Exception {  
  24.         control = MockClassControl.createControl(HibernateTemplate.class);  
  25.         ht = (HibernateTemplate) control.getMock();  
  26.         accountDao = new AccountDao();  
  27.         accountDao.setHibernateTemplate(ht);  
  28.     }  
  29.   
  30.     protected void tearDown() throws Exception {  
  31.            
  32.     }  
  33.       
  34.     public void testFindAccountById(){  
  35.         Account a = new Account("wuhua");  
  36.         a.setId("10");     
  37.           
  38.         ht.get(Account.class, a.getId());  
  39.           
  40.         control.setReturnValue(a);  
  41.           
  42.         control.replay();  
  43.           
  44.         Account result =   accountDao.findAccountById(a.getId());  
  45.           
  46.         assertNotNull(result);  
  47.   
  48.         Assert.assertEquals(a.getId(),result.getId());  
  49.         Assert.assertEquals(a, result);  
  50.           
  51.         control.verify();  
  52.           
  53.     }  
  54.       
  55.     public void testFindAccountByName(){  
  56.         Account a = new Account("wuhua");      
  57.            
  58.         ht.find("from Account as a where a.name=?", a.getName());  
  59.         List l = new ArrayList();  
  60.         l.add(a);  
  61.         control.setReturnValue(l);  
  62.           
  63.         control.replay();  
  64.           
  65.         Account result =  accountDao.findAccounByName(a.getName());  
  66.   
  67.         Assert.assertEquals(a.getId(),result.getId());  
  68.         Assert.assertEquals(a, result);  
  69.           
  70.         control.verify();  
  71.           
  72.     }  
  73. }  
返回顶楼
         
  • pupi
  • 等级: 三星会员
  • 性别:
  • 文章: 247
  • 积分: 271
   发表时间：2007-02-09  
感觉对dao的单元测试还是应该直接操作数据库呢。
写一个专门给测试用的spring配置文件，在这个文件中配置测试数据库，并且放好初始数据。
对hibernatetemplate类，不mock也可以的。
返回顶楼
          回帖地址
0 请登录后投票
  • dengyin2000
  • 等级: 四钻会员
  • 性别:
  • 文章: 1467
  • 积分: 1725
  • 来自: 广州
   发表时间：2007-02-09  
比较赞成LZ的想法。连接数据库耗时，而且实际上是又测试了hibernateTemplate 和 hibernate。
返回顶楼
          回帖地址
0 请登录后投票
  • badqiu
  • 等级: 三星会员
  • 性别:
  • 文章: 211
  • 积分: 360
  • 来自: 珠海
   发表时间：2007-02-09  
争论那么多干啥,测试的标准就是假如测试通过但你的实际代码不能运行那这个测试就不用写了
所以dao没有测试实际数据库也用不着写测试了
返回顶楼
          回帖地址
0 请登录后投票
  • 抛出异常的爱
  • 等级: 五钻会员
  • 性别:
  • 文章: 13663
  • 积分: 2762
  • 来自: 北京
   发表时间：2007-02-09  
hsql在内存里会好一点
那样内存里的逻辑好构造一点
返回顶楼
          回帖地址
0 请登录后投票
  • robbin
  • 等级: 资深会员资深会员
  • 性别:
  • 文章: 6203
  • 积分: 3125
  • 来自: 上海
   发表时间：2007-02-09  
其实连接真实数据库进行DAO测试速度并不慢，这是因为每个DAO测试结束后，会自动rollback恢复环境。

对于一些框架软件，例如springframework来说，要测试的是API实现的逻辑，这种情况下大量mock隔离其他对象的影响是必要的。但是对于我们应用程序，特别是数据处理型应用，你不测试数据库访问，根本就等于没有做测试。换句话说测试DAO就是在测试你的Hibernate映射关系有没有配对，你的HQL查询有没有写对，这一Mock，要测试的真正目标根本就没有达到。

这种DAO测试诚然就是集成单元测试，其实就是对于Web Action测试，我也曾经一度认为应该mock service来测试，但是现在我已经不这样做了，而是真正初始化webwork的容器注入真正的service对象来测试了。因为Action是没有业务逻辑的，测试Action的目标是看xwork.xml有没有配对，拦截器运用是否正确的，这一mock，直接把action对象当做POJO来测试，你只能测试action传了什么参数，其他什么都没有去测，但是action传入什么参数，那是OGNL自动完成的，用不着你多此一举了。

从这个角度来说，只有对util类的测试才是真正的单元测试，其他都是集成测试，但我不觉得这样做有什么不对。特别是我看过ruby on rails的测试框架以后更加坚定了这种做法。rails的unit test，functional test，integration test都是集成测试。
返回顶楼
          回帖地址
0 请登录后投票
  • 抛出异常的爱
  • 等级: 五钻会员
  • 性别:
  • 文章: 13663
  • 积分: 2762
  • 来自: 北京
   发表时间：2007-02-09  
robbin 写道
其实连接真实数据库进行DAO测试速度并不慢，这是因为每个DAO测试结束后，会自动rollback恢复环境。

对于一些框架软件，例如springframework来说，要测试的是API实现的逻辑，这种情况下大量mock隔离其他对象的影响是必要的。但是对于我们应用程序，特别是数据处理型应用，你不测试数据库访问，根本就等于没有做测试。换句话说测试DAO就是在测试你的Hibernate映射关系有没有配对，你的HQL查询有没有写对，这一Mock，要测试的真正目标根本就没有达到。

这种DAO测试诚然就是集成单元测试，其实就是对于Web Action测试，我也曾经一度认为应该mock service来测试，但是现在我已经不这样做了，而是真正初始化webwork的容器注入真正的service对象来测试了。因为Action是没有业务逻辑的，测试Action的目标是看xwork.xml有没有配对，拦截器运用是否正确的，这一mock，直接把action对象当做POJO来测试，你只能测试action传了什么参数，其他什么都没有去测，但是action传入什么参数，那是OGNL自动完成的，用不着你多此一举了。

从这个角度来说，只有对util类的测试才是真正的单元测试，其他都是集成测试，但我不觉得这样做有什么不对。特别是我看过ruby on rails的测试框架以后更加坚定了这种做法。rails的unit test，functional test，integration test都是集成测试。
由于java是工业化工作
所以别人写的代码的错误
会导至你程序的报错

为了画清界线才产生了单元测试。。。

ROR很少有你不经手的逻辑。。。
TDD也使别人写错的代码很快被发现
所以RAILS不用非要去追求单元测试

而如果是java那么。。。
还是老实作mock
DAO是自己写的的但是框架不是
返回顶楼
          回帖地址
0 请登录后投票
  • robbin
  • 等级: 资深会员资深会员
  • 性别:
  • 文章: 6203
  • 积分: 3125
  • 来自: 上海
   发表时间：2007-02-09  
引用
由于java是工业化工作
所以别人写的代码的错误
会导至你程序的报错

为了画清界线才产生了单元测试。。。

ROR很少有你不经手的逻辑。。。
TDD也使别人写错的代码很快被发现
所以RAILS不用非要去追求单元测试

而如果是java那么。。。
还是老实作mock
DAO是自己写的的但是框架不是


测试的策略和你用什么编程语言无关。单元测试也不是为了划清界限才产生的，单元测试为了保证软件的质量，这一点不要想歪了。不管是Java还是Ruby，敏捷软件开发有一个理念，所有的人拥有所有的代码，不管代码是不是你经手的，你都有责任去维护它的质量。单元测试不是为了推卸责任。

rails和Java在单元测试这一点上没有什么区别，本版前面有一个关于mock适用场合的讨论，这里不展开谈，只说结论：mock仅仅适用于测试环境无法重现的部分，例如信用卡支付网关，web容器请求和响应对象等等，mock不应该被滥用。

单元测试的范畴并不单单指隔离所有依赖对象进行单个对象的测试，否则任何对象的测试都必须引入mock，否则单元测试就无法完成的。怎么做单元测试要看你的测试目标，如果偏离了测试的目标，一昧追求纯粹意义上的隔离性，测试根本就是做无用功。
返回顶楼
          回帖地址
0 请登录后投票
  • childpp
  • 等级: 初级会员
  • 文章: 4
  • 积分: 38
  • 来自: ...
   发表时间：2007-03-19  
引用
测试的策略和你用什么编程语言无关。单元测试也不是为了划清界限才产生的，单元测试为了保证软件的质量，这一点不要想歪了。不管是Java还是Ruby，敏捷软件开发有一个理念，所有的人拥有所有的代码，不管代码是不是你经手的，你都有责任去维护它的质量。单元测试不是为了推卸责任。

rails和Java在单元测试这一点上没有什么区别，本版前面有一个关于mock适用场合的讨论，这里不展开谈，只说结论：mock仅仅适用于测试环境无法重现的部分，例如信用卡支付网关，web容器请求和响应对象等等，mock不应该被滥用。

单元测试的范畴并不单单指隔离所有依赖对象进行单个对象的测试，否则任何对象的测试都必须引入mock，否则单元测试就无法完成的。怎么做单元测试要看你的测试目标，如果偏离了测试的目标，一昧追求纯粹意义上的隔离性，测试根本就是做无用功。

完全同意，测试是为了质量，不是为了分清责任
返回顶楼
          回帖地址
0 请登录后投票
  • hyysguyang
  • 等级: 二星会员
  • 性别:
  • 文章: 79
  • 积分: 168
  • 来自: 苏州
   发表时间：2007-04-04  
对达到你目标没有任何帮助的测试用例远比没有测试用例还要糟糕，因为那不但浪费时间还浪费金钱……
所以，请确定你的测试目标，然后确定你的测试策略，之后就写有用的测试用例了.
在我开了，TDD除了提高质量之外，还有很多很多的好处，比如对我的开发效率有非常明显的提高.其他的好处嘛，那些很多经典的文章和书籍都介绍过，Just do it，慢慢的去体会咯
返回顶楼
          回帖地址
0 请登录后投票
论坛首页 → 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics