[请教]Junit测试web开发中的ActionBean的业务方法

07-07-25 gltbeyond
Junit测试可以使我们的代码建立在一个正确的基础上。

我们大多做web开发,采用MVC模式,因为我们的ActionBean里面的callback方法的代码Transaction Script, 纯过程式的代码,都是千行以上的代码。

因为业务逻辑的复杂,实现时都使用简单的条件判断,维护和添加新业务时,测试是很重要的,实现新的功能,又不能败坏原来的逻辑。
过程:本地修改,使用log、System.out.println()打印程序轨迹,make后上传到web服务器,重启服务器,然后模拟各种数据去测试。。。

我们是否可以将ActionBean脱离J2ee容器运行,进行测试? 应该可以。

Junit测试定位在单元测试,
并且要为被测试方法准备必须的环境。
难点就在此,稍微有点规模的MVC框架,都对request的数据进行了封装,为了测试我们的ActionBean的业务方法,必须模拟ActionBean的运行环境。

在ActionBean的运行环境比较复杂的情况下,我是否可以做个替代类
比如采用Mock代替HttpRequest,只需为请求配置好交易数据,传递/注射给ActionBean的方法?

不知道想法是否正确,希望知道的大哥指点下,谢谢。

1
banq
2007-07-26 10:17
思路是可以的。

不过注意JUNIT是单元测试,这个单元也就是使用OO细粒度划分后的单元,所以,OO是前提,象你这样一整块测试,是一个大单元,类似集和测试,测试意义不大,因为逻辑没有细分,都混合在一起,测试条件会复杂,这样测试效果就很差,单元测试往往是针对简单测试条件下精确测试。

所以,有专门业务层,将业务和request这些底层基础机制尽可能分离,才是测试有效的最基本保证。

相关文章:

Unit testing with mock objects

http://www.ibm.com/developerworks/library/j-mocktest.html

JMock
http://www.jmock.org/

gltbeyond
2007-07-29 21:53
谢谢指点!
Junit,jMock都是UT工具,测试业务逻辑的确不大合适,也没多大意义。

我们公司使用自己的开发平台,在假定平台比较稳定的情况下,我们coder必须保证上千行的业务逻辑代码没问题,现在我们只通过简单的System.out和log.debug看看业务逻辑代码的流程...

维护过程式脚本是件十分痛苦的事情!!

jmock is Super Good!

gltbeyond
2007-07-29 22:14
问题依旧, 如何加快web开发中业务逻辑的测试(本地)。
因为web开发中的JavaBean要make,compile到服务器,还要重启服务器或者刷新app,太多coder同时使用一个开发测试环境,几乎乱了套。。

让我们的java ActionBean脱离java web容器,在开发者本地运行测试。

这个测试也许不叫UT了,但构建web运行环境太麻烦。。

jmock maybe help me..

banq
2007-07-30 11:19
主要业务需要脱离Web容器测试,为达到这个目的,整个系统必须进行OO重构,使用OO方法对原来纠缠在一起的逻辑进行细分。

现在Java中测试框架都是基于OO前提的,所以,如果你的系统不是OO的,就很难找到合适的测试工具,或者依赖那些SQL测试及Profiler工具,这些不只是倒退,简直很难执行。


[该贴被banq于2007年07月30日 11:19修改过]

gltbeyond
2007-08-01 22:14
谢谢指点~

我们的TXBean依赖于三个数据容器,一个公共,一个输入,一个输出。和一些DBACCESS,少许的更改类。

当然业务逻辑的封装是面向过程的代码。。。
UT工具很难凑效。
----------------------------------------------------------
基于Junit的CCB交易Bean测试工具(本地测试)V0.2

基于Junit适用CCB5的TXBean业务代码测试工具。

谢谢

可能我们的工作环境不一样

经过两晚的加班 基本上搞定了。共享给大家。。。
使用 Junit,jdom,log4j, 暂时没有使用jMock。

背景、适用CCB5.0:
1。 我们的TXBean extends B2CBean,代码量在600行以上的 。(3000的过程式代码让你修改,你怕怕 ?)
2。 TXBean中都是过程式脚本,对外界的依赖再也IBSEnv,InputArea,OutputArea,和DBACCESS,以及PUB类。
3。 我们的web开发,编码,部署,测试是件麻烦的事情。ccb的测试开发给我的感觉就是:n多人在不停地重启web app.

测试目的:
1。 配合log4j,验证我们TXBean的业务逻辑是否正确,即: 过程式的代码是否如你我所愿
2。 特别是你修改代码时,修改了过多的if-else,真担心复杂的逻辑被你搞坏了。所以看看程序轨迹是件很让你自信的事。
3。 重要一点: 让TXBean可以在你本地运行! 脱离J2EE容器。

实现方式:
1。 更改TXBean的父类:B2CBean,将TXProccess(),AXProcess()方法的三个参数替换掉一个ContextHashtable.
2。 输入参数使用InputArea.xml文件配置。
3。 配合log4j

使用方式:
1。 下载上传的JunitTest_V0.1.rar 解压开,使用Eclipse打开项目,在 glt.ccb5.TXTest目录下,copy进你的TXBean,更改父类为
glt.ccb5.TXTest.B2CBean
基本上无需更改,只需调整package.

2。 在你的TXBean中必须使用log4j来打印程序轨迹,这个必须你自己做。
加入如下代码:
private Logger log = Logger.getRootLogger();
{
BasicConfigurator.configure();
}
在你TXBean中关键地方或者你在意的地方写入 log.debug()...

加入的代码不会影响你的程序,因为在生产环境,root设置的是 priority="info"。

3。 DBACCESS类还没来得及完善,所以你可以自己使用JDBC方式连接。

4。 克服了运行容器,和DB连接,剩下的问题就不多了,就可以在本地jvm中跑跑你的TXBean 过程式的代码了。


存在的问题:
1。 Junit本来是个单元测试工具,现在用来测试业务逻辑,有些无意义。(请教jdon的回复),在我们特殊的国情下,也许用一定的意义。
2。 JMock可以更巧妙地解决很多依赖问题,在使用中我会不停更新,也会继续分享。


欢迎各位同事使用,修改,提出意见。
Email: glt_beyond@126.com


可惜这里不能附件 ;)

[该贴被gltbeyond于2007年08月01日 22:17修改过]

gltbeyond
2007-08-01 22:19
公司的 bbs 有附件下载 V0.2

http://124.42.16.230:8011/bbs/viewthread.php?tid=277&extra=page%3D1

更新版本V0.2

1。 增加JDBC访问的DBACCESS.java , DAC.java (基于测试你的业务流程的目的,你可以屏蔽掉你不关系的PUB方法和类)

2。 增加示例对TX340100Bean的TX方法测试,TX340100Test.

-------------------------------------------


[该贴被gltbeyond于2007年08月01日 22:19修改过]

banq
2007-08-02 13:48
多谢 楼主将实战经验共享,关注中,btw:本论坛可以上传附件,点按发言时上方小图标就可以了。

gltbeyond
2007-08-02 21:54
d

[该贴被gltbeyond于2007年08月03日 09:00修改过]
attachment:


JunitTest_V0.25.rar

猜你喜欢