享受单元测试带来的福利——遗留系统维护随感

     今天客户电话过来，说以前箱重自动分配算法有问题，有一只箱子分配的重量过重，导致箱子在海关被扣下了。

 

     代码是两年多以前写的，一开始有点蒙，当年写的代码时的上下文都已经忘记了。幸好当初把这些自动分配的逻辑都封装在一个类里面，而且我还记得这个类的名字。

 

     翻了翻，单元测试用例也还在。算法实现代码的逻辑已经有些看不懂了，幸好我还记得大概的思路，注释写的还算简单明确。翻了一会代码，发现对一个方法的意义不明，我的命名应该说还是可以的。经过几分钟的摸索，这个方法的意义逐渐明确了，真后悔，当初对一些bean属性没有做注释。

 

    这些帮助我暂时复原了当时的场景， 基本上是从磁带里加载到我的大脑的。接下来，是要准备测试数据，利用发现问题的测试数据，把测试用例跑起来。点击右键Run As JUnit，一个深红色的条出现了。我知道，这肯定是代码里有访问数据库的代码，而数据库有没起来，加载spring bean时出错了。首先要找到这部分代码，我没办法了，只能debug了。我认为，debug是万不得已才用的，很多开发人员全是用debug也不脸红。跟踪了几次，终于发现这部分代码，感叹一下代码写的真不咋地。看了一下，把这部分代码暂时屏蔽掉了。再Run，那条终于绿了，真爽啊。

 

    使用测试的数据，我发现，确实如客户所说，一个箱子分配了31吨。虽然没有超出最大重量40吨，但是其它的箱子都是7，8吨，所以这个箱子被扣了。试着把上限改为30吨，这次还好，最大的一个24吨，但还不是很均衡。我突然想到，可能是最大限制弄错了，稍后的阅读代码，证明了我的直觉。改了这一行代码，将新的测试数据和老的测试数据集成了一下，又Run了一下，发现都绿了。

 

     接下来是将修改代码提交到svn仓库的问题，因为，我修改代码期间修改了其它的部分（如果是一个被把代码修改好的快乐冲昏头的程序员，马上commit，可能会把脏代码一起check in，可能会引起bug）。 同时，我也发现以前的代码格式有些问题，有些地方空了很多行，有些在if下单行的语句体没有加{}。可能是程序员完美的心态，我把这些都改过来了。后来我把本地代码和仓库里的代码比对了一下，发现修改了很多，很乱，没法确认修改了哪些地方，包括逻辑和格式。这时，我想到了另一个修改遗留代码的原则，那就是不要修改已经可以正常工作的代码 。我把这个文件中的代码拷贝出来，然后svn上的最新文件强制更新本地文件。之后，把我要修改的那一行放了上去。当然，放上去之前，又测试了一下，发现还是绿的，这下算放心了（我发现我可能有强迫症）。

 

    我已经在开始享受单元测试带来的福利了。俗话说，前人栽树，后人乘凉，希望每个程序员都能养成写单元测试的习惯，不是每个逻辑都一定要写单元测试，但复杂的逻辑和算法一定要写。今天就栽树吧，即使明天乘凉的可能是别的程序员，但你已经为整个程序员社区营造了良好的环境，而不是你离职前留下的半成品垃圾让后来的我们的同行门受苦。

 

    一棵树仿佛就是一个标杆，下面的树根深植在code base里，而上面是我门可见的，让我们记得当时是什么样的情况。

 

    不管测试先行还是测试后行，关键是要写测试。

 

    assertTrue（You understand it！）；