您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 单元测试 > 正文

有了测试团队,再写单元测试,是否是浪费开发时间呢?

发表于:2019-04-09 作者:小争哥 来源:掘金
在上周发的一篇文章中,我讲到了提高代码质量的几个方法。有读者对其中的单元测试比较感兴趣,今天,我们就聊下:有没有必要写单元测试?有了测试团队,再写单元测试,是否是浪费开发时间呢?

1. 单元测试到底用来测试什么?

以免有读者对单元测试不了解,在讨论这个话题之前,我先简单科普一下,什么是单元测试?

单元测试,顾名思义,它测试的是一个小”单元”,这个”单元”一般是类或方法,而不是模块或者系统。
单元测试一般都是由开发工程师来完成的,是代码层面的测试,用于测试“自己”编写的代码的正确性。
单元测试并不等于测试驱动开发。测试驱动开发是一个理想很丰满,现实不可行的开发思想。而单元测试效果等同于测试驱动开发,但更容易落地执行。
单元测试不依赖于任何不可控的组件,如果代码中依赖了其他这些不可控的组件,比如复杂外部系统,复杂模块或类,则需要通过mock的方式,将这些不可控的部分变成可控。

实际上,写单元测试本身不是一件需要高深技术才能完成的事情,更多的是考验工程师思考的缜密程度,是否能够设计出完备地覆盖各种正常、异常场景的测试用例,来保证代码在任何预期或非预期的情况下都能正确运行。

2. 写单元测试带来的好处有哪些?

从我个人经验来说,当我们写程序的时候,一般都会侧重正常情况下程序的运行是否符合预期,往往会对异常情况下程序的运行情况,考虑不够全面。

在你写完一个功能代码之后,怎么保证你的代码运行正确?在各种异常(数据异常、输入异常、调用异常等)情况下,程序运行结果都符合你预先设计的预期,返回合适的报错呢?

这个时候,单元测试就派上了用场。从我个人写单元测试的经验来看,在写单元测试的时候,几乎每次都会发现很多考虑不全面的地方,都会发现很多”bug“。设计完备的单元测试用例,非常有助于扫清代码中的各种低级的bug。所以,我一直觉得,提高代码质量,最有效的手段,就是写好单元测试。Google中有很多项目是完全没有测试团队参与的。代码的正确性完全靠开发团队来保障,线上bug反倒是非常少。

而且,写单元测试的过程本身就是一个自我code review的过程。在这个过程中,你可以发现一些设计上的问题,比如代码设计的不可测试,代码的可读性不好等等。

写单元测试还能增强你对代码的信心。等你写好完备的单元测试,并且代码通过所有的测试用例的时候,你对自己写的代码也会信心大增。这种一切尽在掌握中的感觉是很好的:)如果你好好写过单元测试,那在这一点上,应该能跟我有所共鸣吧。

除此之外,单元测试还对重构代码也有很大帮助。当你发现某个类或者函数实现的不好,你想要重构一下,但又怕考虑不全面,改了之后会出错,出力不讨好,这个时候该怎么办呢?

如果有单元测试情况就不一样了。代码重构完之后,你跑一下原来的单元测试。如果单元测试都通过,那基本上可以保证,你的重构没有破坏正确性。不过,这个的前提是,之前写的单元测试质量很好,覆盖率很高。

3. 为啥很少有公司会写单元测试?

据我了解,国内的互联网公司,包括BAT在内,很少有认真写单元测试的哈,特别是一些开发业务系统的项目组。我个人觉得,这个跟整个公司的技术文化、研发模式都有关系。

很多公司的技术文化,从上到下都没有“代码质量”的意识。写好代码只要能编译通过,并且正常情况下运行符合预期,就直接提交,然后丢给测试团队,狠命的测。测试团队测出问题后,就反馈给开发团队再修改。测不出的问题就留在线上出了问题再解决。

而且,我们很多公司都是996、995,业务驱动,进度催的紧。研发工程师根本就没有时间、精力,来去写单元测试了。因为,一般情况下,单元测试的代码量往往大于被测代码量,大约会是1-2倍的样子。

在这样的研发模式以及技术文化下,团队往往觉得单元测试没有必要,浪费时间。但是,如果我们开发团队,把单元测试写好,做好code review,重视起代码质量来,其实是对项目的一种长期投资。

有句话说的很好:“慢即是是快”。虽然写单元测试、code review可能暂时会影响当下的研发进度,但是,从长远来看,代码质量很高的项目,整体的研发效率会高很多。

最后

今天,我主要跟你科普一下单元测试,说说单元测试有啥好处。你也可以留言跟我说下,关于单元测试,你还希望听听啥内容?或者说说你对单元测试的看法,你的项目中有没有写单元测试?你觉得是否值得花时间去写呢?


作者:小争哥
链接:https://juejin.im/post/5c91a3a26fb9a070ac669f8c
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。