当前位置: 首页 > >

为什么我们要写单元测试?

发布时间:


?? ? ?今天下午下班前,退款流程改造项目,前台的开发人员觉得现有的流程有个地方不合理:在退款并退货又拒绝退货情况下,如果按照现有流程开发,会让前台界面控制比较麻烦,并且业务上来看也不太合理,大家在一起开了一个会,他们问TC能否把这个流程改造下。


?? ? ?TC使用改造后的JBPM控制退款流程的流转,退款流程去年9月上线后就没有再动过,JBPM相关的代码最初不是我写的,我对里面的配置已经比较陌生了,另外发布日期也快了,在这个项目的尾期,是否还需要接受需求,做比较大的修改,更重要的是,修改后的代码,是不能影响已有的业务逻辑,不能出任何的问题。


?? ? ?我仔细的想了想,首先觉得业务上这个需求是合理的,再想了想需要注意的几个点,好像能够控制,决定接下这个需求。




?? ? ?吃完晚饭回来,翻了RefundServiceBuyerModifyAgreement开头的单元测试,还好,常见的3种业务场景覆盖了2种,异常流覆盖了3种。我根据新的业务场景补了一个单元测试用例,把有修改的几个点加上Assert,然后开始改代码。加Decision节点,加Process Transition,修改JBPM配置文件,按照新的流程加了一个新的路径,然后改了业务代码,并增加一个Dao方法满足新的需求。


?? ? ?在这个过程中,发生一个小插曲,我运行了一遍单元测试,本来期望会抛出一个异常(业务代码还没实现),没想到居然看到绿条,突然想起,我只是修改了正式环境的配置文件,没有修改单元测试环境的配置文件,它还是走的老流程。打开Total Commander,用快捷键进入需要同步的两个配置文件目录,祭出Beyond Compare,同步后,然后去Eclipse F5了几下,果然,这次是期望的红条。


?? ? ?半个小时后,所有编码完成。为新流程加的单元测试也看到了绿条。我把所有的代码SVN同步后,一次性提交到服务器。


?? ? ?然后登录到CruiseControl的服务器,cd到为本次改造建立的持续集成项目,svn up后,运行mvn clean test,其间,我还忙里偷闲,拿出今天快递刚到的09年春季福建铁观音,泡了杯好茶。等了3分钟,所有测试都跑完了,挂了3个Case,我在本地Eclipse中跑了下,果然跑不过,然后打开Excel准备的初始化数据,找到出问题那个Case的退款记录和交易记录,开始觉得是:初始化数据的退款状态有问题,改正了后,在Eclipse中F5了几下,再跑,本来期望能见到绿色,还是红色,并且还是抛了一个异常。


?? ? ?看来是我把以前好的代码改坏了,仔细看了下代码,发现是流程引擎的配置文件的问题:调用这个流程的地方有两个点,而我只改了这次改造相关的一个点。我将剩下的一个点也改了,再跑,果然是绿色。这个错误还是比较隐蔽,如果等到功能测试再发现这个问题,需要我去跟踪,定位,修改,提交,找人重新部署到测试环境,然后再叫功能测试人员去Redo测试,Close BUG,至少需要花两个小时的时间;如果测试遗漏发到线上,那就麻烦了。


?? ? ?提交前,我发现新建类名有些不合理,使用Eclipse的重构工具,换了个比较容易理解的类名,提交,然后在CruiseControl服务器跑全套单元测试,600多个Case都过了,这次没有问题。


?? ? ?然后我ssh到我们的149服务器将我这次修改的代码更新,打包,重新部署,发布成服务。我在本地Eclipse中切换到集成测试工程,将集成测试目标服务地址从日常测试环境切换到149服务器,运行全套的集成测试,10分钟后,90多个测试跑完,没问题。我看了看表,还有5分钟到8点。


?? ? ?


?? ? ?我想这就是我们为什么要坚持写覆盖全面的单元测试的原因,即使这会花掉我们额外的很多时间。因为:?


    有了这些测试,我们能够知道这次的修改至少不会影响以前的功能。可以对代码变化不那么惧怕,对自己代码有信心,才能更好的拥抱变化。在开发阶段解决大部分BUG,让开发和测试都更加轻松。

??? 实际上,单元测试和写说明文档一样,看上去是个花时间,牺牲效率的工作,但是,如果你写了一些代码却完全不知道它会不会正常的Run起来,如果你天天被一群人在旺旺上问这问那,花时间写单元测试绝对是划算的买卖。?? ? ?








?? ? ?





友情链接: hackchn文档网 营销文档网 爱linux网 爱行业网 时尚网