锁定老帖子 主题:从自身体会谈一谈测试
精华帖 (0) :: 良好帖 (6) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-01-21
还是从我目前所处项目组的情况说起吧,整个项目开发的架构是从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这一层写测试? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-01-22
正在郁闷dao和业务逻辑层耦合在一起如何test的人飘过。
ps:或许对一个业务逻辑类中dao部分可以用AbstractTransactionalDataSourceSpringContextTests,业务逻辑部分直接mock后做单元测试。只是这样做,感觉有点...。 |
|
返回顶楼 | |
发表时间:2008-01-22
action
如果没有逻辑多好啊.... 一般是用selenium IDE在ff上面. 把测试顺序录下来测试. |
|
返回顶楼 | |
发表时间:2008-01-22
你们分的层太多了,不够pragmatic
另外,如果不涉及到对外通信、远程调用的话,用mock隔离测试的意义不大,还不如做集成测试 比如对action的测试,可以如楼上说的那样——用selenium IDE在ff上面录制脚本,copy到junit里面来跑,这个虽然也是用junit来写,但称呼上应该称为FunctionTest加以区别。好处就是连验收测试的回归都可以自动化了 参考SpringSide |
|
返回顶楼 | |
发表时间:2008-01-22
zdonking 写道 正在郁闷dao和业务逻辑层耦合在一起如何test的人飘过。
ps:或许对一个业务逻辑类中dao部分可以用AbstractTransactionalDataSourceSpringContextTests,业务逻辑部分直接mock后做单元测试。只是这样做,感觉有点...。 这样太麻烦了,只测业务逻辑类就行(用AbstractTransactionalDataSourceSpringContextTests),dao自然就被覆盖到了 |
|
返回顶楼 | |
发表时间:2008-01-22
这样也会引起其他的麻烦。比如如何做到数据无关性,dbunit之类的吗?维护那么一份测试数据也够恶心的。(曾经造数据造的想吐)
但如果dao的粒度比较细。造数据就不用考虑太多的数据关联性,甚至可以不用dbunit之类的辅助工具。 ps:web层不包含业务逻辑的话,测试的意义应该不大吧。或许一些公共的action需要做一些正常转向,异常转向等的测试吧。 |
|
返回顶楼 | |
发表时间:2008-01-22
daquan198163 写道 你们分的层太多了,不够pragmatic
另外,如果不涉及到对外通信、远程调用的话,用mock隔离测试的意义不大,还不如做集成测试 比如对action的测试,可以如楼上说的那样——用selenium IDE在ff上面录制脚本,copy到junit里面来跑,这个虽然也是用junit来写,但称呼上应该称为FunctionTest加以区别。好处就是连验收测试的回归都可以自动化了 参考SpringSide 有一小部分内容涉及了远程调用,不过不多。 "用selenium IDE在ff上面录制脚本,copy到junit里面来跑",其实比较早就听说这一个东西,但一直没有去尝试。今晚空闲的时候再下载一个新的springside来看一下。分层我们一般都至少四层,写一个普通的CRUD我都快麻木了,没有办法,这一个框架是银行的人里面给定用的,你只能按着规范来写! |
|
返回顶楼 | |
发表时间:2008-01-22
zdonking 写道 这样也会引起其他的麻烦。比如如何做到数据无关性,dbunit之类的吗?维护那么一份测试数据也够恶心的。(曾经造数据造的想吐)
但如果dao的粒度比较细。造数据就不用考虑太多的数据关联性,甚至可以不用dbunit之类的辅助工具。 ps:web层不包含业务逻辑的话,测试的意义应该不大吧。或许一些公共的action需要做一些正常转向,异常转向等的测试吧。 数据无关性?你的意思是说测试数据互相干扰的问题吧?这个问题Spring的那个测试基类可以解决,每个测试结束它替我们回滚事务。 造数据我不用dbunit,因为还要额外维护数据文件,我一般在setup里面用dao往数据库插数据,现学现卖 ps:web层也有自己的逻辑,比如validator、参数处理、视图转发,还有view里的显示逻辑,都需要测试,selenium擅长做这些 |
|
返回顶楼 | |
发表时间:2008-01-22
你忘记说在tearDown删去刚刚插入的数据了.
PS:如何才能用hibernate方便的对表结构查询呢? (如果建表就更好了) 我用hsqldb想要建表都要写多个hbm.xml |
|
返回顶楼 | |
发表时间:2008-01-22
不用在tearDown删去刚插入的数据,Spring的那个测试基类AbstractTransactionalDataSourceSpringContextTests(我见过的名字最长的类)可以在每个测试结束后替我们回滚事务
ps:对表结构查询?建表?什么意思 |
|
返回顶楼 | |