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

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

下面，针对单元测试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();
   }

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