日常啰嗦

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

你愿意进行单元测试吗？

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

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

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

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

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

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

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

  • 做了少量的单元测试。

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

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