关于单元测试，还想发点牢骚目前项目一直没有单元测试，所以大家一直在呼唤着口号，要把单元测试用起来，测试
关于单元测试，还想发点牢骚
目前项目一直没有单元测试，所以大家一直在呼唤着口号，要把单元测试用起来，测试能不能驱动开发不好说（我觉得这个很难），至少测试能帮助减少一些问题的产生吧，在刚开始使用单元测试的时候，不必在意测试是在代码之前写还是之后写，能用起来并达到“测试不是开发的累赘而是帮助开发的工具”状态就是现阶段的任务。
下面，针对单元测试junit以及我微薄的理解，阐述一下我的牢骚所在吧
首先我认为，传统过程的单元测试是典型的白盒测试，一段代码产生可能在任何地方产生错误，这种错误有可能是一个异常中断，一个错误的返回值，存储数据库的时候少存一条记录，发送给远程客户端的信息不完整等等各种各样，而junit只能以黑盒方式，即返回值捕获可能出现的错误，因为单元测试错误出现的多样性，几乎不可能抽象出一种统一的方式来捕捉所有类型的错误。如果只有junit，那么能做的事情很少，好在我们有JMOCK,ORMUNIT,DBUNIT,XMLUNIT....等等工具来帮助测试，在经典的开发环境下（就像论坛里大多数人所处环境一样），junit配合那些工具能帮助程序将很多问题发现在萌芽里。
我仔细的看了POJO IN ACTION里面关于单元测试使用的例子
一个业务类的测试大概是这个形式：
public doSomething(){ BookDao dao = getBookDao(); }protected BookDao getBookDao() { return new BookDao();}然后要测试的话，用一个子类重载一下getBookDao函数即可。 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的惯用写法,不用专门说,对于应自己公司开发的框架就不好说了..
