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

       前段日子很无聊，也是很无奈的。经过了这段日子的，我想了很多事情，虽然全部想通，但却努力的去想了。我想这样就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 {}

}

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

评论

32 楼 hyysguyang 2006-12-08  

kenny319 写道

hyysguyang 写道

gigix 写道

hyysguyang 写道

gigix 写道

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

如果了解持续集成的任何一个同行，可能都认可你所说的，可是，如果不了解持续集成，那就不一定像你所说的乐。我不知道国内有多少公司在进行严格的测试？实施持续集成这样的东东。我所知道的很多人，他们宁愿花N多时间去看什么Spring，学其他的大量的开源框架。当然，我并不是说这样不好，但是，我认为，有些基础设施更重要，就像单元测试应该是每个开发人员最基本的工具（实际上这是一把锋利的宝剑）。我并不是说开源不好，事实上我相信我对开源的兴趣并不亚于他们。我难以理解的是，他们去研究开源的东西，却不学开源里面的东西，比如，测试，日构建，持续集成，自动发布等。上面我说过，其实测试入门很难，特别是TDD，可是，从开源社区，我学到了很多，rod也建议，写测试最好从开源代码开始。

我完全赞同你说的，不过你略微误解了我的意思。我说的不是要每个人都认可，而是从制度上强迫遵守。break build之后什么都停下，第一件事就是fix build，我相信这个事情容易并且值得从制度上强制推行。

我明白你说的意思，所以我才说那个是人的问题，不是技术的问题，这几天有几个同事也在讨论编程习惯的问题，大家也这么认为，对于编程习惯不是很好的，跟着监督一段时间，然后久习惯了。
因此，我所说的那些问题，正如你所说的可以从管理的角度强制执行，一段时间也就习惯了，这个是管理的问题。
我想其实这些正如我们使用java开发一样，这么多人都习惯于写java代码，等到哪一天，测试(或者说TDD)，持续集成等这些东西大家都习惯了，那个时候一切也就水到渠成了。

前提是你的同事愿意被监督吧。TDD，持续集成这些东西要求管理上要有很强的执行力才行，现在大部分的软件都还是业务驱动，加上个人的水平和习惯的不同，真正执行起来真的很难。

的确很困难，中国缺的就是执行力，那个是管理的问题，我对管理不是很在行，呵呵，因此我认为好的习惯很重要。

31 楼 kenny319 2006-12-08  

hyysguyang 写道

gigix 写道

hyysguyang 写道

gigix 写道

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

如果了解持续集成的任何一个同行，可能都认可你所说的，可是，如果不了解持续集成，那就不一定像你所说的乐。我不知道国内有多少公司在进行严格的测试？实施持续集成这样的东东。我所知道的很多人，他们宁愿花N多时间去看什么Spring，学其他的大量的开源框架。当然，我并不是说这样不好，但是，我认为，有些基础设施更重要，就像单元测试应该是每个开发人员最基本的工具（实际上这是一把锋利的宝剑）。我并不是说开源不好，事实上我相信我对开源的兴趣并不亚于他们。我难以理解的是，他们去研究开源的东西，却不学开源里面的东西，比如，测试，日构建，持续集成，自动发布等。上面我说过，其实测试入门很难，特别是TDD，可是，从开源社区，我学到了很多，rod也建议，写测试最好从开源代码开始。

我完全赞同你说的，不过你略微误解了我的意思。我说的不是要每个人都认可，而是从制度上强迫遵守。break build之后什么都停下，第一件事就是fix build，我相信这个事情容易并且值得从制度上强制推行。

我明白你说的意思，所以我才说那个是人的问题，不是技术的问题，这几天有几个同事也在讨论编程习惯的问题，大家也这么认为，对于编程习惯不是很好的，跟着监督一段时间，然后久习惯了。
因此，我所说的那些问题，正如你所说的可以从管理的角度强制执行，一段时间也就习惯了，这个是管理的问题。
我想其实这些正如我们使用java开发一样，这么多人都习惯于写java代码，等到哪一天，测试(或者说TDD)，持续集成等这些东西大家都习惯了，那个时候一切也就水到渠成了。

前提是你的同事愿意被监督吧。TDD，持续集成这些东西要求管理上要有很强的执行力才行，现在大部分的软件都还是业务驱动，加上个人的水平和习惯的不同，真正执行起来真的很难。

30 楼 hyysguyang 2006-12-08  

gigix 写道

hyysguyang 写道

gigix 写道

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

如果了解持续集成的任何一个同行，可能都认可你所说的，可是，如果不了解持续集成，那就不一定像你所说的乐。我不知道国内有多少公司在进行严格的测试？实施持续集成这样的东东。我所知道的很多人，他们宁愿花N多时间去看什么Spring，学其他的大量的开源框架。当然，我并不是说这样不好，但是，我认为，有些基础设施更重要，就像单元测试应该是每个开发人员最基本的工具（实际上这是一把锋利的宝剑）。我并不是说开源不好，事实上我相信我对开源的兴趣并不亚于他们。我难以理解的是，他们去研究开源的东西，却不学开源里面的东西，比如，测试，日构建，持续集成，自动发布等。上面我说过，其实测试入门很难，特别是TDD，可是，从开源社区，我学到了很多，rod也建议，写测试最好从开源代码开始。

我完全赞同你说的，不过你略微误解了我的意思。我说的不是要每个人都认可，而是从制度上强迫遵守。break build之后什么都停下，第一件事就是fix build，我相信这个事情容易并且值得从制度上强制推行。

我明白你说的意思，所以我才说那个是人的问题，不是技术的问题，这几天有几个同事也在讨论编程习惯的问题，大家也这么认为，对于编程习惯不是很好的，跟着监督一段时间，然后久习惯了。
因此，我所说的那些问题，正如你所说的可以从管理的角度强制执行，一段时间也就习惯了，这个是管理的问题。
我想其实这些正如我们使用java开发一样，这么多人都习惯于写java代码，等到哪一天，测试(或者说TDD)，持续集成等这些东西大家都习惯了，那个时候一切也就水到渠成了。

29 楼 hyysguyang 2006-12-08  

wuhua 写道

这里插句题外话：
根据我们老总几十年得出的经验

工资的优先级比 单元测试、重构、持续集成、模式、面向对象 。

这是他说的
不过话有说回来，足以证明测试在高手心目中的地位

不是很明白：”工资的优先级比 单元测试、重构、持续集成、模式、面向对象 。“，说得是什么意思呢？是不是说优先级是从低到高的这样排列：单元测试、重构、持续集成、模式、面向对象

28 楼 wuhua 2006-12-08  

楼上说的对。
是它从事开放的时间，并不是有了那些TDD后的时间。
就是经验了。

27 楼 daquan198163 2006-12-08  

clamp 写道

wuhua 写道

这里插句题外话：
根据我们老总几十年得出的经验

工资的优先级比 单元测试、重构、持续集成、模式、面向对象 。

这是他说的
不过话有说回来，足以证明测试在高手心目中的地位

几十年前？重构、持续集成、模式这些概念在几十年前还在摸索阶段吧……

可能是几十年的教训，在看到这些敏捷实践后自然会有相见恨晚的感觉

26 楼 clamp 2006-12-08  

wuhua 写道

这里插句题外话：
根据我们老总几十年得出的经验

工资的优先级比 单元测试、重构、持续集成、模式、面向对象 。

这是他说的
不过话有说回来，足以证明测试在高手心目中的地位

几十年前？重构、持续集成、模式这些概念在几十年前还在摸索阶段吧……

25 楼 wuhua 2006-12-08  

这里插句题外话：
根据我们老总几十年得出的经验

工资的优先级比 单元测试、重构、持续集成、模式、面向对象 。

这是他说的
不过话有说回来，足以证明测试在高手心目中的地位

24 楼 gigix 2006-12-08  

抛出异常的爱 写道

你说的build 是指冒烟测试还是指每日构建?

持续集成
每日构建没用的，要是等一天才知道build failed，估计起码得花半天时间来排错。

23 楼 抛出异常的爱 2006-12-08  

你说的build 是指冒烟测试还是指每日构建?

22 楼 gigix 2006-12-08  

hyysguyang 写道

gigix 写道

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

如果了解持续集成的任何一个同行，可能都认可你所说的，可是，如果不了解持续集成，那就不一定像你所说的乐。我不知道国内有多少公司在进行严格的测试？实施持续集成这样的东东。我所知道的很多人，他们宁愿花N多时间去看什么Spring，学其他的大量的开源框架。当然，我并不是说这样不好，但是，我认为，有些基础设施更重要，就像单元测试应该是每个开发人员最基本的工具（实际上这是一把锋利的宝剑）。我并不是说开源不好，事实上我相信我对开源的兴趣并不亚于他们。我难以理解的是，他们去研究开源的东西，却不学开源里面的东西，比如，测试，日构建，持续集成，自动发布等。上面我说过，其实测试入门很难，特别是TDD，可是，从开源社区，我学到了很多，rod也建议，写测试最好从开源代码开始。

我完全赞同你说的，不过你略微误解了我的意思。我说的不是要每个人都认可，而是从制度上强迫遵守。break build之后什么都停下，第一件事就是fix build，我相信这个事情容易并且值得从制度上强制推行。

21 楼 抛出异常的爱 2006-12-08  

gigix 写道

hyysguyang 写道

抛出异常的爱 写道

什么上瘾?我的同事都退回去不写测试了

当初用EJB才强迫他们用的...

我的同事何尝不是这样，主要是他们写测试而不去遵循基本的写单元测试的原则，不去遵循一定的策略，因此，对与他们来说写测试代码只会是一种额外的工作，耽误时间。
此外，很多同事不愿去了解测试的相关理论，他不去了解为什么这么做，也不去实践，你跟他说了，他也不认同。跟何况，写测试代码对于生手来说的确很难，或者说TDD入门很难，我已经花了很多时间了，还没入门呢，不过我越来越喜欢它了。
还有，TDD的很多好处只有你去实践了，你才会体会的到，否则，你永远都体会不到的，我们同事，大多数对于测试的理解都停留在大学里的古老的软件工程里提到的那点测试而已，而且根深蒂固的认为，测试是测试组的事。他们宁愿花很多时间在调试，在debug，也不愿写测试。
7月份，我在我们的项目中引入持续集成，在引入之前我发了N多邮件，说了N多基本的原则，可是那有怎么样？出错了都邮件通知了，告诉你有bug了，可是没人去改，build几十次了，惟独成功过一次，而且那次还是花了很大的精力去复查的，可是过来几天，有回去了。对我们来说，持续集成有一定的效果，但是收效并不大。我现在面临的最大的困难就是怎么去说服其他人，可是有些事，我想我怎么也做不到。郁闷死了。幸好，我可以自娱自乐。

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

现在没有作到所以.....
看来每个环节都有一定的意义
敏捷真是个有机的整体...

20 楼 hyysguyang 2006-12-07  

不好意思，好像走题了，看来以后有问题就直接找你们了，请多多指教！
没有人指教的日本，很不好过哦。呵呵。

19 楼 hyysguyang 2006-12-07  

我只能说这是人的问题，不是技术的问题，实际上，我认为，技术不是问题，敏捷说的不错，左>右

18 楼 hyysguyang 2006-12-07  

gigix 写道

hyysguyang 写道

抛出异常的爱 写道

什么上瘾?我的同事都退回去不写测试了

当初用EJB才强迫他们用的...

我的同事何尝不是这样，主要是他们写测试而不去遵循基本的写单元测试的原则，不去遵循一定的策略，因此，对与他们来说写测试代码只会是一种额外的工作，耽误时间。
此外，很多同事不愿去了解测试的相关理论，他不去了解为什么这么做，也不去实践，你跟他说了，他也不认同。跟何况，写测试代码对于生手来说的确很难，或者说TDD入门很难，我已经花了很多时间了，还没入门呢，不过我越来越喜欢它了。
还有，TDD的很多好处只有你去实践了，你才会体会的到，否则，你永远都体会不到的，我们同事，大多数对于测试的理解都停留在大学里的古老的软件工程里提到的那点测试而已，而且根深蒂固的认为，测试是测试组的事。他们宁愿花很多时间在调试，在debug，也不愿写测试。
7月份，我在我们的项目中引入持续集成，在引入之前我发了N多邮件，说了N多基本的原则，可是那有怎么样？出错了都邮件通知了，告诉你有bug了，可是没人去改，build几十次了，惟独成功过一次，而且那次还是花了很大的精力去复查的，可是过来几天，有回去了。对我们来说，持续集成有一定的效果，但是收效并不大。我现在面临的最大的困难就是怎么去说服其他人，可是有些事，我想我怎么也做不到。郁闷死了。幸好，我可以自娱自乐。

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

如果了解持续集成的任何一个同行，可能都认可你所说的，可是，如果不了解持续集成，那就不一定像你所说的乐。我不知道国内有多少公司在进行严格的测试？实施持续集成这样的东东。我所知道的很多人，他们宁愿花N多时间去看什么Spring，学其他的大量的开源框架。当然，我并不是说这样不好，但是，我认为，有些基础设施更重要，就像单元测试应该是每个开发人员最基本的工具（实际上这是一把锋利的宝剑）。我并不是说开源不好，事实上我相信我对开源的兴趣并不亚于他们。我难以理解的是，他们去研究开源的东西，却不学开源里面的东西，比如，测试，日构建，持续集成，自动发布等。上面我说过，其实测试入门很难，特别是TDD，可是，从开源社区，我学到了很多，rod也建议，写测试最好从开源代码开始。

17 楼 gigix 2006-12-07  

hyysguyang 写道

抛出异常的爱 写道

什么上瘾?我的同事都退回去不写测试了

当初用EJB才强迫他们用的...

我的同事何尝不是这样，主要是他们写测试而不去遵循基本的写单元测试的原则，不去遵循一定的策略，因此，对与他们来说写测试代码只会是一种额外的工作，耽误时间。
此外，很多同事不愿去了解测试的相关理论，他不去了解为什么这么做，也不去实践，你跟他说了，他也不认同。跟何况，写测试代码对于生手来说的确很难，或者说TDD入门很难，我已经花了很多时间了，还没入门呢，不过我越来越喜欢它了。
还有，TDD的很多好处只有你去实践了，你才会体会的到，否则，你永远都体会不到的，我们同事，大多数对于测试的理解都停留在大学里的古老的软件工程里提到的那点测试而已，而且根深蒂固的认为，测试是测试组的事。他们宁愿花很多时间在调试，在debug，也不愿写测试。
7月份，我在我们的项目中引入持续集成，在引入之前我发了N多邮件，说了N多基本的原则，可是那有怎么样？出错了都邮件通知了，告诉你有bug了，可是没人去改，build几十次了，惟独成功过一次，而且那次还是花了很大的精力去复查的，可是过来几天，有回去了。对我们来说，持续集成有一定的效果，但是收效并不大。我现在面临的最大的困难就是怎么去说服其他人，可是有些事，我想我怎么也做不到。郁闷死了。幸好，我可以自娱自乐。

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

16 楼 hyysguyang 2006-12-07  

抛出异常的爱 写道

什么上瘾?我的同事都退回去不写测试了

当初用EJB才强迫他们用的...

我的同事何尝不是这样，主要是他们写测试而不去遵循基本的写单元测试的原则，不去遵循一定的策略，因此，对与他们来说写测试代码只会是一种额外的工作，耽误时间。
此外，很多同事不愿去了解测试的相关理论，他不去了解为什么这么做，也不去实践，你跟他说了，他也不认同。跟何况，写测试代码对于生手来说的确很难，或者说TDD入门很难，我已经花了很多时间了，还没入门呢，不过我越来越喜欢它了。
还有，TDD的很多好处只有你去实践了，你才会体会的到，否则，你永远都体会不到的，我们同事，大多数对于测试的理解都停留在大学里的古老的软件工程里提到的那点测试而已，而且根深蒂固的认为，测试是测试组的事。他们宁愿花很多时间在调试，在debug，也不愿写测试。
7月份，我在我们的项目中引入持续集成，在引入之前我发了N多邮件，说了N多基本的原则，可是那有怎么样？出错了都邮件通知了，告诉你有bug了，可是没人去改，build几十次了，惟独成功过一次，而且那次还是花了很大的精力去复查的，可是过去几天，有回去了。对我们来说，持续集成有一定的效果，但是收效并不大。我现在面临的最大的困难就是怎么去说服其他人，可是有些事，我想我怎么也做不到。郁闷死了。幸好，我可以自娱自乐。

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

什么上瘾?我的同事都退回去不写测试了

当初用EJB才强迫他们用的...

14 楼 hyysguyang 2006-12-07  

抛出异常的爱 写道

TDD主要是为了开发而设计的
无关的测试都放到后面由QA与监理去作吧

快速完成功能...
快速达到期望的值才是正途
及使手写个return true也是必须的

呵呵，TDD说起来容易，做起来来，但是一旦你习惯了，就习惯了，正如有些牛人所说的那样，TDD容易让人上瘾。
只可惜，很难说服你周围的人跟你一样，去实施TDD，这是我比较困惑，比较郁闷的一点。

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

TDD主要是为了开发而设计的
无关的测试都放到后面由QA与监理去作吧

快速完成功能...
快速达到期望的值才是正途
及使手写个return true也是必须的