Spring+SpringMVC+MyBatis+easyUI整合优化篇（三）代码测试

日常啰嗦

看到标题你可能会问为什么这一篇会谈到代码测试，不是说代码优化么？前两篇主要是讲了程序的输出及Log4j的使用，Log能够帮助我们进行bug的定位，优化开发流程，而代码测试有什么用呢？其实测试是为了验证自己所编写的代码，及时排除错误，减少bug，所以我认为，减少错误也是优化的一个方案体现，而且如果进行了合理的单元测试，也可以帮助优化开发流程，一旦出现问题，使得bug的定位过程更加迅速。

你愿意进行单元测试吗？

其实，像第一篇文章所说的，对于打印输出信息，我们更习惯于使用System.out命令，所以很多时候，习惯决定了我们的编码方式，那么你习惯于做单元测试吗？

我感觉很多人可能都不是很乐忠于在开发工作做这件事，因为主观意识中会觉得这是一件"麻烦"的事情，或者说效果不是很明显的一件事。

针对于此，我也粗略的整理了一下根由，对各个原因，也分别谈一下自己的想法，当然，都是个人看法，大家觉得有用就看，觉得无用忽略即可。

• 开发项目时并没有明确的要求我去写单元测试。

因为没人要求，所以就不写单元测试。我认为作为一个技术人员，应该关注自我增值和技术上的提升，要求应该是自己提给自己的，并不是说项目没有要求或者没人督促我们就不去做一些事情了，这种装鸵鸟式的态度和钻空子的小聪明不值得提倡，我们不仅要对项目负责，其实更多的也是对自己负责，严格要求自己，多学习，才能更快的进步，不要随波逐流，不要进入其他人的节奏中。

• 业务逻辑比较简单不值得编写单元测试。

这又是一个理由，而这个理由的深层次的原因，应该是来源于对自己的自信，自信是件好事，但是要掌握好其中的度。相对于机器来说，拥有主观意识的人类更容易犯一些错误，错误可能不大，或者是一些低级错误，比如忘记写一个分号、忘记判空、忘记类型转换...这些都是小错误，但是不注意的话就会出现bug，然后再去花时间修修补补。
所谓的业务逻辑比较简单，其实是相对的。当你对某一块业务逻辑很熟悉的时候，你自然会认为它很简单。然而，单元测试的必要性并不是仅仅在于测试代码的功能是否正确，还在于，当其他同事在了解你的业务的时候，能够很快的通过单元测试来熟悉代码的功能，甚至不用去读代码，就能够知道它做了哪些事情。因此，写单元测试不仅是解放了自己，更方便了别人。

• 做了少量的单元测试。

这里可能有几方面的原因：
1、为了完成编码任务，没有足够的时间编写单元测试。
2、在项目的前期还是尽量去编写单元测试，但是越到项目的后期就越失控。
3、和上一个原因类似，对自己足够自信，于是只挑一小部分进行单元测试。

我们简单的梳理一下开发过程，开发过程：需求—>编码—>自测—>预发布—>测试—>回滚—>改bug—>发布—>发现bug—>改bug—>发布……我们可以观察到，整个过程中改bug出现了很多次，它与编码工作一样，都是开发过程中不可缺少的一部分，编码只是整个开发过程中的一部分，开发不仅仅是编码而已。
编码的完工≠项目的完工。
因为自测的不完备，导致预发布过程或者后期的冒烟测试难度加大，加长回滚和bug修复过程，这是一个自相矛盾的事情。

• 测试人员会抓住所有的bug，用不着进行单元测试。

也会有人把锅丢给测试，可能存在这样一个观点，既然有测试了，干嘛还要我费那么多精力去写测试用例？
但是测试工程师往往不在意代码层面，其测试工作只是业务上的集成测试，也就是我们熟知的黑盒测试，更多的是进行功能测试，对代码中单个方法是没有办法进行测试的，因此，测试出的bug的范围也会很广，根本不能确定bug的范围及发生的原因，所以问题的定位及bu*生的原因，还得去花一些时间来确认，如果已经进行了自测，知道了哪部分代码是健康的，至少可以缩小检查的范围，减少定位bug所花的时间。而且，单元测试也就是顺手的一件事，虽然不能解决百分百的麻烦，但是给各方人员提供的便利也是很多的。

• 不会写。

想当初刚进入这个行业，我压根儿不知道这个事情，也根本没有单元测试的概念，因为那时候我连开发工作都做的不是很好，更不要提过程优化了，直到一段时间后，熟悉了开发流程，可以把开发做好的时候，才开始慢慢接触流程优化，但是一开始碰到的问题就是，我不会。
其实网上教程也是很多的，下一篇会进行简单的介绍和教程，代码也会放到github中，不会可以学，但是不做的话就有些不负责任了。

代码测试的重要性及必要性

测试常常是程序员十分厌倦的一个事情。测试能给我们带来什么？了解这些是非常重要的，测试不可能保证一个程序是完全正确的，但是测试却可以增强我们对程序完整的信心，测试可以让我们相信程序做了我们期望它做的事情。测试能够使我们尽早的发现程序的bug和不足。
当然，我们主要讨论的是单元测试。单元测试是一个方法层面上的测试，也是最细粒度的测试。用于测试一个类的每一个方法都已经满足了方法的功能要求。在开发中，对于自己开发的模块，只有在通过单元测试之后，才能提交到SVN库或者Git 库。
再一次强调，你不是一个人，你的代码有问题，同事pull下来的代码也是有问题的，浪费大家的时间。对于这件事情，我是深有感触的，在去年的一次项目开发过程中，由于我没有做好代码审查和单元测试匆匆上传到代码库，导致其他开发人员也无法正常开展工作，还要帮着我去修改bug，这件事导致我有些自责，也在后续的开发工作中更认真，更专注，虽然偶尔也会犯错，但是在态度上不再吊儿郎当、无关痛痒，代码测试有时候也能体现出一个人的态度问题。
知道测试的重要性最好，只要写就是对项目和编码认真的体现，虽然一开始可能写的不是很好很完善，迈出第一步就是正确的，随着测试编码的增多，测试用例也会逐渐完善，关键是要明确和认识到单元测试的重要性。

最终目的

前面论述了一下单元测试难以推进的原因以及单元测试的重要性，当我们开始认真的去做这件事了，我们也要做好这件事，我们想要追求的是完美，即使无法十全十美，也要尽自己的全力去争取写出漂亮的代码，漂亮指得是易读、简洁、健壮，为了达到这个目的，我们就需要做覆盖率高以及更完善的单元测试。
测试的覆盖率和完备性越高对于项目来说就越是一个利好的信号，即使做了单元测试，但是较为懒散，随随便便写了几个测试用例，这不能算得上单元测试，这种行为不仅是对项目不负责任，也是对自己不负责任。
不能和不为区别是很大的，不能代表的就是你没有能力去做到一件事，而不为则是明明能做到却不做。对于不能，那么首先要做的，就是通过自己的努力和学习将不能变为能，可能现在项目中并没有做单元测试，原因是因为不会，那就要学习如何去进行单元测试，掌握这个技能。

结语

认真些，端正自己的态度，做好自己的单元测试。

(怎么感觉说出这些话的我这么正气凛然，我不像是个刚正不阿的五道杠青年啊，哈哈哈哈哈。)