论坛上关于测试的帖子很多,而且有一部分是一些大牛写的,看得也比较有感触.在这一个帖子里面主要谈一下,自己关于测试的一些理解.

还是从我目前所处项目组的情况说起吧,整个项目开发的架构是从DAO层-BS层-BIZ层-Action展现层,典型的J2EE分层的结构,从名字中就可以看得出DAO层是只对数据库进行操作的,BS层主要处理大量的业务方法,而BIZ层是干什么用的呢?其实BIZ主要是负责事务管理和用户的权限控制的;另外,Action当然是表示层的东西啦,搞java开发的地球人都听说过这一个称谓。在这里，并不想评论公司开发的架构的思想怎样怎样，毕竟论坛里面已讨论了N次，在这里只是想把自身对单元测试的一些体会写出来。开发的时候主要用到的技术情况主要有JSF/WebWork+hibernate+spring，前台方面还大量用了Ext和DWR两个东东。

就目前的项目里20多人，真正愿意写单元测试的其实并不多，大多是怕写测试代码影响了他自己的开发速度，其实这根本是一个伪命题。写代码以及测试的代码相对整个开发流程而言,并不多,相反比较的是你想好怎样去实现这一个功能,还有实现该功能后针对的调整维护会占用比较大的时间.

就目前我对于自己开发的模块，是这样写测试代码的:
对于所有的util公共方法，我基本上都用JUnit来测试。从自身体会来讲，用JUnit来测试一些输出输入很简单，但里面算法处理比较复杂的时候，更显得其测试特别特别有用，这一点感触最深。说到测试，就不能不提一下重构。从我自身体会觉得，如果一个程序员自己没有真正地写过一些的JUnit测试，就对"有效的测试给了重构更多的信心"类似于这样的言语说理解很深刻的话，我根本就不信，根本就是从书上学来的放出来的屁话。我自身是从尝试写JUnit测试到现在变得非常自然地写JUnit测试，因为这样做给了我更大的信心，心里就知道了"哦，这和我想要的一样啦,我可以往下面走了"。顺便八卦一下，半年多来，感觉对自己的开发影响比较大的两本书是<<agile java>>和<<重构>>。

对于很多的DAO方法，我都是这样做的:
利用构建好的一个Hibernate的Flush方法的Interceptor拦截器,实现了里面的public Object invoke(MethodInvocation invocation) throws Throwable方法后,再构建一个BaseDAOTest来继承于spring的AbstractTransactionalDataSourceSpringContextTests测试类来对大部分的DAO方法进行测试.具体不知道怎样做的朋友,可以搜索一下论坛,有大把这样的例子.

对于大部分的BS和BIZ层方法，是利用EasyMock测试驱动写的。在我们的这样的项目组里面的，因为分层多，每一个层次的职责很明确，每一层都是用接口隔离开的，所以这样对EasyMock这样的Mock框架就大有用途了。可惜的是,只能用EasyMock1.2的包,因为我们开的的环境只能用1.4的java SDk。如果可以用EasyMock2.x版本上的时候，测试的代码量就会少一些，但需要JDK 1.5以上的版本啊。没有试过JMock，不知道好不好用。

说到Action层方面，我有一个疑问，想请教一下大家。目前我们项目里面有两个专门进行验收测试的人员，也就是每天对每一个页面的一些细节功能都进行测试，有BUG的话会记录在JIRA或其他的缺陷管理工具上面。现在Action层我们是用JSF，大多情况下是调用BIZ层的接口进行一个数据的展现和编辑,而且很多方法都和EXT,DWR都有一些交互动作。在这种情况下，如果我还是用Mock的情况下，感觉就显得有测试比较脆弱---毕竟项目里面有两个专门进行验收测试的人员,每天都会进行一些回归测试。 所以我想问一下，对于这种情况的Action怎样测试才比较好,才能达到比较好的效果或者就采用目前的形式---根本就没有针对Action这一层写测试?