从自身体会谈一谈测试

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

还是从我目前所处项目组的情况说起吧,整个项目开发的架构是从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这一层写测试?

正在郁闷dao和业务逻辑层耦合在一起如何test的人飘过。
ps:或许对一个业务逻辑类中dao部分可以用AbstractTransactionalDataSourceSpringContextTests，业务逻辑部分直接mock后做单元测试。只是这样做，感觉有点...。

action
如果没有逻辑多好啊....
一般是用selenium IDE在ff上面.
把测试顺序录下来测试.

你们分的层太多了，不够pragmatic
另外，如果不涉及到对外通信、远程调用的话，用mock隔离测试的意义不大，还不如做集成测试
比如对action的测试，可以如楼上说的那样——用selenium IDE在ff上面录制脚本，copy到junit里面来跑，这个虽然也是用junit来写，但称呼上应该称为FunctionTest加以区别。好处就是连验收测试的回归都可以自动化了
参考SpringSide

这样太麻烦了，只测业务逻辑类就行（用AbstractTransactionalDataSourceSpringContextTests），dao自然就被覆盖到了

这样也会引起其他的麻烦。比如如何做到数据无关性，dbunit之类的吗？维护那么一份测试数据也够恶心的。（曾经造数据造的想吐）
但如果dao的粒度比较细。造数据就不用考虑太多的数据关联性，甚至可以不用dbunit之类的辅助工具。
ps:web层不包含业务逻辑的话，测试的意义应该不大吧。或许一些公共的action需要做一些正常转向，异常转向等的测试吧。

有一小部分内容涉及了远程调用，不过不多。
"用selenium IDE在ff上面录制脚本，copy到junit里面来跑"，其实比较早就听说这一个东西，但一直没有去尝试。今晚空闲的时候再下载一个新的springside来看一下。分层我们一般都至少四层，写一个普通的CRUD我都快麻木了,没有办法，这一个框架是银行的人里面给定用的,你只能按着规范来写!

数据无关性？你的意思是说测试数据互相干扰的问题吧？这个问题Spring的那个测试基类可以解决，每个测试结束它替我们回滚事务。
造数据我不用dbunit，因为还要额外维护数据文件，我一般在setup里面用dao往数据库插数据，现学现卖

ps：web层也有自己的逻辑，比如validator、参数处理、视图转发，还有view里的显示逻辑，都需要测试，selenium擅长做这些

你忘记说在tearDown删去刚刚插入的数据了.
PS:如何才能用hibernate方便的对表结构查询呢?
(如果建表就更好了)
我用hsqldb想要建表都要写多个hbm.xml

不用在tearDown删去刚插入的数据，Spring的那个测试基类AbstractTransactionalDataSourceSpringContextTests（我见过的名字最长的类）可以在每个测试结束后替我们回滚事务

ps：对表结构查询？建表？什么意思