我的第一个真正意义上的测试

       前段日子很无聊，也是很无奈的。经过了这段日子的，我想了很多事情，虽然全部想通，但却努力的去想了。我想这样就Ok了
对吗？
       好了。前阵子，老板请喝早茶，顺便跟我们这些技术人员讨论了怎么样可以提高我们内功的问题。我老板也是技术出身的。有相当多的经验，当然我最初的想法并不是去研究测试，我直接提出：“我觉得我们应该提高我们对设计模式的理解”。他却不怎么同意，说测试才是我们现在的当务之急，然后很肯定的说。TDD，重构都是建立再单元测试基础上的。并推翻了我的建议：”有空让对设计模式有深厚理解的员工给我们上课“。
       开始由于我个人原因，或许我是个很情绪话的员工，也许在另外一家公司我可能早就被T。也许老板对我太好了。^_^
我当时不怎么响应，总是做自己喜欢做的事情，后来自己慢慢觉得自己的工作态度不对，所以昨天试着努力纠正自己的错误，真是在这样的环境下，自己写出了自己第一个我认为真正意义上的测试，把它记录下来。
       测试的要求：
       测试对一个Account的Dao操作以及Service。

java 代码

//先来测试最基本的dao吧
package org.wuhua.dao;

import java.util.Collection;

public interface IBaseDao {
    Object save(Object o);
    void delete(Object o);
    Object update(Object o);
    Collection list();
}

根据我的理解，测试的对方要跟mock的对象分开，（开始我一直认为你要mock的对象就是你要测试的东西，搞着搞着，我就很迷茫了。）。现在要做的就是看你IBaseDao的实现是什么了。如果实现是采用SpringHibernateTemplate的话你就去mock一个这样对象，不过此对象并不是接口，所以你要用到easymock的扩展包，以对它的支持。如果你实现的采用纯Hibernate的话。那你就去mock一个SessionFactory吧。很简单吧，难道这就是所谓的解耦吗？我想是的，这正是解耦。 哈哈

看下我的实现吧，采用Spring实现。

java 代码

package org.wuhua.dao.impl;

import java.util.Collection;

import org.springframework.orm.hibernate3.support.HibernateDaoSupport;
import org.wuhua.dao.IBaseDao;

public class BaseDao extends  HibernateDaoSupport
implements IBaseDao {

    public void delete(Object o) {
         this.getHibernateTemplate().delete(o);
    }

    public Collection list() {

        return null;
    }

    public Object save(Object o) {
        return this.getHibernateTemplate().save(o);

    }

    public Object update(Object o) {
        this.getHibernateTemplate().update(o);
        return o;
    }

}

测试代码

java 代码

package org.wuhua.dao;

import java.io.Serializable;

import junit.framework.TestCase;

import org.easymock.MockControl;
import org.easymock.classextension.MockClassControl;
import org.springframework.orm.hibernate3.HibernateTemplate;
import org.wuhua.dao.impl.BaseDao;

public class BaseDaoTest extends TestCase {

    MockControl control;

    private HibernateTemplate ht;

    private BaseDao baseDao;

    protected void setUp() throws Exception {
        control = MockClassControl.createControl(HibernateTemplate.class);
        ht = (HibernateTemplate) control.getMock();
        baseDao = new BaseDao();
        baseDao.setHibernateTemplate(ht);
    }

    public void testSave() {
        Object o = new Object();
        ht.save(o);
        //这里我是有疑问的。
        //1,为什么HibernateTemplate返回的是Serializable。
        //2,设置的返回植为什么一定要跟调用ht.save(o)一致呢？
        control.setReturnValue(new Wuhua());
        control.replay();
        baseDao.save(o);
        control.verify();
    }

    public void testUpdate() {
        Object a = new Object();
        ht.update(a);

        control.replay();
        try {
            baseDao.update(a);
            fail("Not catch exception!");
        } catch(Exception e) {

        }
        control.verify();
    }

    class Wuhua implements Serializable {}

}

上面就是我第一次很认真的测试，有很多不明白的地方

评论

12 楼 hyysguyang 2006-12-07  

wuhua 写道

补充一句：
关于Dao测试的问题
1用mock来测试
2直接用真实环境去测试

1。
如果用mock的话，我只是测试我Dao实现是否按照自己预期的效果去测。比如，你mock HibernateTemplate，然后调用find(hsql),好现在的测试结果是，测试的时候将会比较这两次hsql
是否一致，至于hsql是对是错，自己可以再写一个测试专门来负责测试HibernateTemplate.find(hsql)方法。这样对于定位错误是比较有好处的。也就是细分测试的问题
至于第2个网上讨论的也不少，而起本人对此的理解还很普通

还是那个原则，有逻辑就采用plain的方式测，mock也好stub也吧，否则，直接进行集成单元测试就OK了。
对与数据库DAO的测试，我也是这样的，有逻辑我就可能mock，否则，就直接连接数据库的测试。

我不知道这样对不对，因此我遵循这样的原则：如果对某个功能不放心，就写相应的测试，否则就OK了。这也是我从without ejb上学到的。的确，以前我一直不知道我该怎么测？该不该测。
，还想，自从遵循这个原则之后没有那么困惑了。

11 楼 hyysguyang 2006-12-07  

wuhua 写道

受教了。

觉得很有道理。如果纯粹是为了验证自己的写的SQL是否错误，难道就一定要用数据库去验证吗？
没有其他更好的办法，或者更优雅的解决方法吗？

呵呵，你不应该认为，我们只提到sql就认为只是为了验证sql，也许还包括其他的，比如，如果你使用乐存储过程，或者触发器之类的。
事实上，我也不认为必须要连接数据库，如果我现在只是为了测我写的SQL对不对，而且我已经有了某一个工具（比如，自己写一个检查SQL语法的工具，当然，你这个工具要能够集成进你的测试代码中），那我像我不会去连接数据库的。因为比较连接数据库还是很慢的，而测试的速度必须尽可能的快。

10 楼 wuhua 2006-12-07  

补充一句：
关于Dao测试的问题
1用mock来测试
2直接用真实环境去测试

1。
如果用mock的话，我只是测试我Dao实现是否按照自己预期的效果去测。比如，你mock HibernateTemplate，然后调用find(hsql),好现在的测试结果是，测试的时候将会比较这两次hsql
是否一致，至于hsql是对是错，自己可以再写一个测试专门来负责测试HibernateTemplate.find(hsql)方法。这样对于定位错误是比较有好处的。也就是细分测试的问题
至于第2个网上讨论的也不少，而起本人对此的理解还很普通

9 楼 wuhua 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是否错误，难道就一定要用数据库去验证吗？
没有其他更好的办法，或者更优雅的解决方法吗？

8 楼 hyysguyang 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的测试，一般都进行所谓的的集成单元测试。我认为，你应该确定好你的测试策略，然后在去采用相应的测试方法。我在目前的开发中就是采用这样的方式测的。

7 楼 抛出异常的爱 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----- 测试起来很方便但是业务简单的话...好麻烦...

6 楼 wuhua 2006-12-07  

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

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

5 楼 抛出异常的爱 2006-12-07  

如果不连接数据库
那为什么要分dao层?
service层

4 楼 wuhua 2006-12-07  

也就是测试Dao还是要连接数据库才是有意义的吗？

3 楼 抛出异常的爱 2006-12-07  

用内存库进行测试DAO
我是在setup时将数据写到那个表中
而在teardown时将所有表中的数据清除
(不要用hibernate的删除,用jdbc的会快一到二个数量级....)

2 楼 wuhua 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错了。测试是通过不了的

1 楼 robbin 2006-12-07  

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