导语:非常幸运的是,从4月份至今,我能够全身心投入到腾讯新闻的单元测试专项任务中,从无知懵懂,到不断深入理解的过程,与开发同学互帮互助,受益匪浅。 在此过程中,得到了质量总监、新闻总监和乔帮主的倾囊指导,真心感谢!! 我希望把所有心得,总结成一篇较为全面的文章,分享给其他团队。 时刻牢记:
· 不要滥用mock
· 基于意图
在我们谈到单元测试,大都清楚是测试函数符合预期,国外很多大公司都将单测执行的很好,国内成功的案例则相对有限。在本文中,笔者将在腾讯新闻项目中亲身经历单测从无到有的实践过程梳理为可读可参考的经验分享出来。在实践的过程我发现,单测可以推动产品质量转为优秀,推动实行它的过程更需要对它有真实的认识以及一套方法论。
一. 为单元测试"正名"
我曾经认为,单元测试面向的是一个函数。任何走出一个函数的测试,都不是单元测试。
其实,对"单元"的定义取决于自己。如果你正在使用函数式编程,一个单元最有可能指的是一个函数。你的单元测试将使用不同的参数调用这个函数,并断言它返回了期待的结果;在面向对象语言里,下至一个方法,上至一个类都可以是一个单元(从一个单一的方法到一整个的类都可以是一个单元)。意图很重要("意图"二字是本文中第一次提到,它很重要)
我们有单元测试、增量测试、集成测试、回归测试、冒烟测试等等,名字非常多。谷歌看到这种"百家争鸣"的现象,创立了自己的命名方式,只分为小型测试、中型测试和大型测试。
· 小型测试,针对单个函数的测试,关注其内部逻辑,mock所有需要的服务。小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告
· 中型测试,验证两个或多个制定的模块应用之间的交互
· 大型测试,也被称为"系统测试"或"端到端测试"。大型测试在一个较高层次上运行,验证系统作为一个整体是如何工作的。、
结论:我们的单元测试,既可以针对一个函数写case,也可以按照函数的调用关系串起来写case。
二、为什么做单测
这个问题我们规避不掉。新闻是这次研发模式改革的主力军之一,所以自上而下的推动让这个问题不那么棘手:做了就是做了。不做,却又有那么多的理由:
(搜集到的吐槽真实声音)
· 单元测试浪费了太多的时间
· 单元测试仅仅是证明这些代码做了什么
· 我是很棒的程序员,我是不是可以不进行单元测试?
· 后面的集成测试将会抓住所有的bug
· 单元测试的成本效率不高我把测试都写了,那么测试人员做什么呢?
· 公司请我来是写代码,而不是写测试
· 测试代码的正确性,并不是我的工作
我觉得我们总监指导的很到位:改革,一是工作方式的改革,更难的是思想上的改革。
单元测试的意义
新闻的总监dot老师是至始至终推进单测的好领导,他讲述了螺丝钉与飞机的故事:
· 单元测试对我们的产品质量是非常重要的。
· 单元测试是所有测试中最底层的一类测试,是第一个环节,也是最重要的一个环节,是唯一一次有保证能够代码覆盖率达到100%的测试,是整个软件测试过程的基础和前提,单元测试防止了开发的后期因bug过多而失控,单元测试的性价比是最好的。
· 据统计,大约有80%的错误是在软件设计阶段引入的,并且修正一个软件错误所需的费用将随着软件生命期的进展而上升。错误发现的越晚,修复它的费用就越高,而且呈指数增长的趋势。作为编码人员,也是单元测试的主要执行者,是唯一能够做到生产出无缺陷程序这一点的人,其他任何人都无法做到这一点。
· 代码规范、优化,可测试性的代码
· 放心重构
· 自动化执行three-thousand times
下面这张图,来自微软的统计数据:bug在单元测试阶段被发现,平均耗时3.25小时,如果漏到系统测试阶段,要花费11.5小时。
下面这张图,旨在说明两个问题:85%的缺陷都在代码设计阶段产生,而发现bug的阶段越靠后,耗费成本就越高,指数级别的增高。所以,在早期的单元测试就能发现bug,省时省力,一劳永逸,何乐而不为呢。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理