|
锁定老帖子 主题：我的第一个真正意义上的测试
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-12-07
前段日子很无聊，也是很无奈的。经过了这段日子的，我想了很多事情，虽然全部想通，但却努力的去想了。我想这样就Ok了
对吗？ 好了。前阵子，老板请喝早茶，顺便跟我们这些技术人员讨论了怎么样可以提高我们内功的问题。我老板也是技术出身的。有相当多的经验，当然我最初的想法并不是去研究测试，我直接提出：“我觉得我们应该提高我们对设计模式的理解”。他却不怎么同意，说测试才是我们现在的当务之急，然后很肯定的说。TDD，重构都是建立再单元测试基础上的。并推翻了我的建议：”有空让对设计模式有深厚理解的员工给我们上课“。 开始由于我个人原因，或许我是个很情绪话的员工，也许在另外一家公司我可能早就被T。也许老板对我太好了。^_^ 我当时不怎么响应，总是做自己喜欢做的事情，后来自己慢慢觉得自己的工作态度不对，所以昨天试着努力纠正自己的错误，真是在这样的环境下，自己写出了自己第一个我认为真正意义上的测试，把它记录下来。 测试的要求： 测试对一个Account的Dao操作以及Service。 java 代码
看下我的实现吧，采用Spring实现。 java 代码
java 代码
声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2006-12-07
测试DAO不如连数据库一起测试吧。因为DAO测试的目的不是DAO接口实现对不对，而是测试是否如你预期的发送了SQL，如你预期的返回了结果集。这个时候你Mock之后，测试就没有意义了。
|
| 返回顶楼 | |
|
发表时间：2006-12-07
那这段代码也是mock的，它的测试原理也是发送SQL，但是也没有真正的连接数据，而起，也可以得到预期的效果
public void testGetAccount(){
Account a = new Account("wuhua");
a.setId("10");
List list = new ArrayList();
list.add(a);
ht.find("from Account as a where a.id=?", a.getId());
control.setReturnValue(list);
control.replay();
List ls = (List) accountDao.findAccountById(a.getId());
assertNotNull(ls);
Assert.assertEquals(1, ls.size());
Account ac = (Account) ls.get(0);
Assert.assertEquals(a.getId(),ac.getId());
Assert.assertEquals(a, ac);
control.verify();
}
//这是真正的实现代码
public Collection findAccountById(String id) {
return this.getHibernateTemplate().find("from Account as a where a.id=?" , id);
}
也就测试的时候如果你from Account as a where a.id=?这个语句错了。跟Id错了。测试是通过不了的 |
| 返回顶楼 | |
|
发表时间：2006-12-07
用内存库进行测试DAO
我是在setup时将数据写到那个表中 而在teardown时将所有表中的数据清除 (不要用hibernate的删除,用jdbc的会快一到二个数量级....) |
| 返回顶楼 | |
|
发表时间：2006-12-07
也就是测试Dao还是要连接数据库才是有意义的吗？
|
| 返回顶楼 | |
|
发表时间：2006-12-07
如果不连接数据库
那为什么要分dao层? service层 |
| 返回顶楼 | |
|
发表时间：2006-12-07
分层的原因很多。这里我的看法片面就不说了
但对于mock来说是有莫大好处的。 比如service测试的时候完全可以做到隔离数据库， 我现在的意思是， 居然Service可以隔离Dao层，也就是说Dao层也是可以做到隔离相关的数据实现的。也是可以mock一个对象。而并非用实际的连接去代替。如果我们的逻辑没出错的话，测试就算通过了，至于数据层的检测，那就不关我们的事情了，比如Hibernate由Hibernate去test，Spring由Spring去Test，Oracle由它自己去做。干自己的事情，别趟其他浑水。这样不是潇洒很多吗 |
| 返回顶楼 | |
|
发表时间：2006-12-07
wuhua 写道 分层的原因很多。这里我的看法片面就不说了
但对于mock来说是有莫大好处的。 比如service测试的时候完全可以做到隔离数据库， 我现在的意思是， 居然Service可以隔离Dao层，也就是说Dao层也是可以做到隔离相关的数据实现的。也是可以mock一个对象。而并非用实际的连接去代替。如果我们的逻辑没出错的话，测试就算通过了，至于数据层的检测，那就不关我们的事情了，比如Hibernate由Hibernate去test，Spring由Spring去Test，Oracle由它自己去做。干自己的事情，别趟其他浑水。这样不是潇洒很多吗 jsp --- web ----service ------dao ----db jsp-----web 这个很难测试 dao-----db 这个用内存测试 ----service----- 测试起来很方便但是业务简单的话...好麻烦... |
| 返回顶楼 | |
|
发表时间：2006-12-07
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的测试，一般都进行所谓的的集成单元测试。我认为，你应该确定好你的测试策略，然后在去采用相应的测试方法。我在目前的开发中就是采用这样的方式测的。 |
| 返回顶楼 | |
|
发表时间：2006-12-07
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的测试，一般都进行所谓的的集成单元测试。我认为，你应该确定好你的测试策略，然后在去采用相应的测试方法。我在目前的开发中就是采用这样的方式测的。 受教了。 觉得很有道理。如果纯粹是为了验证自己的写的SQL是否错误，难道就一定要用数据库去验证吗？ 没有其他更好的办法，或者更优雅的解决方法吗？ |
| 返回顶楼 | |
