你的代码，我来守护

每个编码的人都有一个梦想：能够按照随心所欲地编写代码，而不用担心集成时会发生这样或那样的问题。

这个梦想并不遥远，只要你实现了自动化的单元测试。

单元测试，可以确保代码的正确性；自动化的单元测试，可以让代码的每一次变动都有了一个安全保障。

单元测试的作用并没有人来否认，但它依然经常被抛弃、被拒绝。一个烂大街的理由是单元测试会花费很多时间，而我们的项目没有那么多时间，我们还有很多功能要完成。

其实，单元测试只是对你编写的代码进行验证，就算你不进行单元测试，你就不需要对你编写的代码进行验证了吗？

想象一下，你把包含一堆错误的代码提交给集成人员，那你就等着迎接集成人员的怒火吧！

所以，即使不进行单元测试，也会做代码调试。通常你都会如下进行：

写一小块代码，然后嵌入一些输出语句，来看一些关键变量的值；又或者在调试器中使用桩代码来运行程序。你会手工查看运行结果，然后解决发现的问题。

而单元测试所做的，和你调试的过程并没有什么两样。所不同的只是，单元测试是将桩代码保存下来，以使其能够持续运行；同时，检查变量值这样的事情，也不用人工来做，只要代码来完成。

所以，单元测试一直都没有离开你，他一直都在。说单元测试会耗费大量的时间，那可能你根本没有找准测试的方向，在一些毫无价值的属性方法上浪费了大量时间。而且，单元测试没有实现自动化，人工的单元测试也会占用大量时间。

自动化单元测试是这样一个过程：

在后台有一个构建机器，它能够不断获得源代码，然后编译，并运行单元测试，把发现的错误通报给你。

有了自动化的单元测试，就像有了守护天使。你可以随意重构代码，根据需要重新设计，而自动化的单元（回归）测试会随时保护你不会破坏软件的任何功能。你写下任一行代码不再会担惊受怕、如履薄冰。

从某个角度来说，自动化的单元测试也是敏捷的反馈。代码一出来，就有单元测试来告诉你代码正确与否，这不就是非常“敏捷”的反馈吗？

实际上，自动化的单元测试已经是非常普遍的做法，它的实现也并没有那么困难，任何你所知道的开发环境和语言都已经有了标准的单元测试框架。那么，追求高效开发的你，还会杜绝自动化单元测试吗？

这正是：

单元测试作用大，及时反馈好代码

只要实现自动化，修改代码没再怕

参考书目：《高效程序员的45个习惯-敏捷开发修炼之道》

作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。