大约在两年前，我在太极做项目，写完了code，为了通过验收（因为做的是外包项目），开始写Unit Testing case。按照要求，写一个成功的，写一个失败的。当时的感想有两点，写Unit Testing case几乎没有必要，除非针对非常复杂或者自己拿不准的函数才写，二是像太极那样写case就更加没有意义了。
现在觉得上述第二点仍然是正确的，因为那种case是为了有case而写，完全没有必要，还浪费了大量的人力。对提高代码质量没有任何意义，相反，还加入了一堆没有用的测试code。
第一点完全不正确。
重构，毋庸置疑，是提高代码质量很好的一种方式。但是，简单到重命名一个变量名，复杂到改变类的结构，如何能保证你的修改正确呢？那就是做测试。
这两天在修复一个Bug，顺手重构了两个函数。很简单，就是改变了for循环if条件判断的结构，使得代码更简单，更易懂。二是将方法修改成扩展方法，使得调用的code和自然语言更为接近。三是根据现有业务逻辑（不会影响到原有的设计，是一个兼容的修改）修改了某个分支的判断条件。
之后我在测试函数里面添加了两个新的用例，测试一下新的逻辑。顺手右键跑了一下针对这两个函数的测试case，得到一个红色的叉叉。以为是新的用例写的不对，结果是之前的用例没有通过。我勒个去。。。
仔细检查了一下code，发现重构的时候漏写了一个感叹号（非运算符）。改过来，继续做测试，得到一个绿色的对勾。
即使再简单的重构，有一个Unit Testing跑一下，确保修改无误，更安心。因为人毕竟是人，做什么事情都有可能出错。而有了完善的case，不费多少事，就能确保code重构之后的行为和之前一致。相反，没有这些保障，那么就只能靠重构的人就小心翼翼的处理各个环节，伤神不说，还不能保证是100%正确。
我在想，如果没有Unit Testing，这个少了个运算符的错误应该也会被发现。运气好，code review的时候由其他人发现和原有逻辑不完全一致，提出个疑问，我会修改一下。其实这种可能性微乎其微的。之后按照流程部署Edog，让测试测试是否修复了该bug，并看一下是否引起了regression。这个时候应该能发现这个问题。但是意味着这个时候再修改代码，build，部署Edog，再让测试去测试。
我损失了时间（同时也浪费了测试的时间），虽然build和部署时间也就一个小时多，而且敲命令看各种信息的时间不会超过15分钟，但是，势必打断了自己当前的工作，回头还要再次进入状态，浪费精力。有这时间和精力，看看书，或者多干点活都不错。哪怕是休息去了，那咱也是为了以后更好的工作。
我这里发生的是一个小事，但是也能体现出Unit Testing的重要性。遇到更复杂的案例，充分并且及时的测试才能保证代码质量，才能提高生产力。没有充分且及时的测试，虽然短期看来省了时间，但是之后的维护工作更加棘手，会出现更多的问题，耗费更多的精力和时间去弥补。出来混，早晚都是要还的。测试很重要，开发人员顺手写一个Unit Testing case，就能避免很多不必要的麻烦，向贡献高质量代码走出一小步。