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

      今天下午下班前，退款流程改造项目，前台的开发人员觉得现有的流程有个地方不合理：在退款并退货又拒绝退货情况下，如果按照现有流程开发，会让前台界面控制比较麻烦，并且业务上来看也不太合理，大家在一起开了一个会，他们问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点。

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

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

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