关于单元测试，还想发点牢骚

目前项目一直没有单元测试，所以大家一直在呼唤着口号，要把单元测试用起来，测试能不能驱动开发不好说（我觉得这个很难），至少测试能帮助减少一些问题的产生吧，在刚开始使用单元测试的时候，不必在意测试是在代码之前写还是之后写，能用起来并达到“测试不是开发的累赘而是帮助开发的工具”状态就是现阶段的任务。

下面，针对单元测试junit以及我微薄的理解，阐述一下我的牢骚所在吧
首先我认为，传统过程的单元测试是典型的白盒测试，一段代码产生可能在任何地方产生错误，这种错误有可能是一个异常中断，一个错误的返回值，存储数据库的时候少存一条记录，发送给远程客户端的信息不完整等等各种各样，而junit只能以黑盒方式，即返回值捕获可能出现的错误，因为单元测试错误出现的多样性，几乎不可能抽象出一种统一的方式来捕捉所有类型的错误。如果只有junit，那么能做的事情很少，好在我们有JMOCK,ORMUNIT,DBUNIT,XMLUNIT....等等工具来帮助测试，在经典的开发环境下（就像论坛里大多数人所处环境一样），junit配合那些工具能帮助程序将很多问题发现在萌芽里。
我仔细的看了POJO IN ACTION里面关于单元测试使用的例子
一个业务类的测试大概是这个形式：

Class Book{   
    BookDao dao ;   
    public Book(BookDao dao){   
       this.dao = dao;   
    }   
  
    public doSomething(){   
       ......   
    }   
}   
//想对这个book类的doSomething()作测试大致是这个样子   
Class usertest extends  MockObjectTestCase{   
   private Mock daoMock;   
   private Book;   
   public viod setUp(){   
       daoMock = new Mock(BookDao.class);   
       BookDao = (BookDao)daoMock.proxy();   
       Book = new Book(BookDao);   
   }   
   public void testDoSomething(){   
       daoMock.expects(once())   
              .method("add")   
              .with(eq(1))   
              .will(returnValue(true));   
       Book.doSomething();   
   }   

    Class Book{
        BookDao dao ;
        public Book(BookDao dao){
           this.dao = dao;
        }

        public doSomething(){
           ......
        }
    }
//那么想对这个book类的doSomething()作测试大致是这个样子
    Class usertest extends  MockObjectTestCase{
       private Mock daoMock;
       private Book;
       public viod setUp(){
           daoMock = new Mock(BookDao.class);
           BookDao = (BookDao)daoMock.proxy();
           Book = new Book(BookDao);
       }
       public void testDoSomething(){
           daoMock.expects(once())
                  .method("add")
                  .with(eq(1))
                  .will(returnValue(true));
           Book.doSomething();
       }
   }

问题就出在于并非项目中每个人都这样写book，而有人也许会这样写

Class Book{   
    public doSomething(){   
       BookDao dao = new BookDao();   
    }   
}  

    Class Book{
        public doSomething(){
           BookDao dao = new BookDao();
        }
    }

这样，BookDao非构造子注入，没办法用代理对象替换了，也许这样写的业务类就是不可测试的。。。
我在这里并不想和大家讨论这样写代码的开发人员素质是否高的问题，我想发的牢骚在于，测试本身和开发就是两种不同的思路，而单元测试并非轻易而使，他需要开发业务的人员去分心，除了沉陷于繁冗复杂的业务中以外，还要考虑如何写代码才能让代码可测试化。。这似乎有点本末倒置了。想实现单元测试，看来首先要知道如何写可测试的业务代码之后才考虑测试类怎么写。

这些看起来大家并不觉得有什么的，按照传统的SSH惯用方法业务类，通过ioc工厂让组件脱离于框架限制而成为“可本地化”的pojo类，则天然地也成为了可测试类。
但是对于一个不能用开源框架，只许用“用来向客户兜售”的公司内部框架开发，而且很多时候框架限制只能把类写成

   public doSomething(){
     BookDao dao = new BookDao();
   }

形式的时候，单元测试就显得不那么简单了。

评论

6 楼 unsid 2009-01-23  

regular 写道

实际上说白了，既然你doSomething函数写成了这个样子，想把其中一块挖出去，用其它对象替代感觉是不太可能。而且……也没必要吧。 如果一定要用MOCK代替BookDAO，除非新建一个package，然后把mock放在那里。然后引用的包改成新建的包。 这是一个就不打算让你测的例子。因为如果想给别人测的话，写成这样就行了：


Java代码

public doSomething(){      
  BookDao dao = getBookDao();      
}   
  
protected BookDao getBookDao() {   
  return new BookDao();   
}  public doSomething(){  
  BookDao dao = getBookDao();  
}

protected BookDao getBookDao() {
  return new BookDao();
}
然后要测试的话，用一个子类重载一下getBookDao函数即可。

那其实也就等于说,要想在没有单元测试的地方,慢慢起用单元测试,首先要给开发人员制定规范,所有人严格按规范写,知道怎么能写,怎么不能写,通常用惯了SHH的人习惯性的都写成那种可测试的风格,因为SHH的惯用写法,不用专门说,对于应自己公司开发的框架就不好说了..

5 楼 regular 2009-01-23  

实际上说白了，既然你doSomething函数写成了这个样子，想把其中一块挖出去，用其它对象替代感觉是不太可能。而且……也没必要吧。

如果一定要用MOCK代替BookDAO，除非新建一个package，然后把mock放在那里。然后引用的包改成新建的包。

这是一个就不打算让你测的例子。因为如果想给别人测的话，写成这样就行了：

public doSomething(){   
  BookDao dao = getBookDao();   
}

protected BookDao getBookDao() {
  return new BookDao();
}

然后要测试的话，用一个子类重载一下getBookDao函数即可。

4 楼 regular 2009-01-23  

TestNG。去看看。

3 楼 lzy.je 2009-01-18  

unsid 写道

lzy.je 写道
单元测试的粒度控制是重点，尤其是在引入这项任务的前期。

呵呵,这个您有什么高见,我认为写领域模型有助于细化单元测试的粒度,粒度细了,覆盖率就高了,如果一个业务写成一个事务脚本,虽然业务好实现,单元测试则起不到什么实质作用了.

我说的粒度两个层次，技术和非技术。

单元测试用例的多少确实和覆盖度有关系，不过反过来就不一定了，不能说用例少覆盖度就上不去，对吧。关于实现，我觉得stub、mock肯定少不了，否则高阶用例肯定没法搞定。
另外，这项工作涉及到工作量的问题，粒度细了覆盖率上去了，可要知道工作量自然也是增加不少了。这就是项目管理方面的问题。

你觉得呢？

2 楼 unsid 2009-01-18  

lzy.je 写道

单元测试的粒度控制是重点，尤其是在引入这项任务的前期。

呵呵,这个您有什么高见,我认为写领域模型有助于细化单元测试的粒度,粒度细了,覆盖率就高了,如果一个业务写成一个事务脚本,虽然业务好实现,单元测试则起不到什么实质作用了.

1 楼 lzy.je 2009-01-18  

单元测试的粒度控制是重点，尤其是在引入这项任务的前期。