点击次数:277      更新时间:2017-04-21 10:02:00       作者:本站整理      来源:www.lan6.net        QQ交流群:626957820


 

日常啰嗦

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

你愿意进行单元测试吗?

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

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

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

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

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

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

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

  • 做了少量的单元测试。

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

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

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

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

  • 不会写。

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

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

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

最终目的

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

结语

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

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