一、写在前面的话
作为编程从业人员,单元测试早已不是生僻的、不为人知、不受重视的概念。
但是与此同时,实际情况下,除了开源SDK基本上会标配单元测试外,在真正的项目开发中,单元测试的实践程度低之又低。
这里面的原因非常非常多,笔者听到的最多的不写单元测试的原因就是 —— 没时间!
但是没时间是否能和'可有可无'画等号?是否能和'不重要'画等号?
也就是说,假设给到足够充足的时间,是否单元测试就能够顺利实施?覆盖率就能达到100%?
笔者后面会针对这些问题阐述笔者自己的理解。
二、不考虑时间的情况下,到底有没有必要搞单元测试?
假设有这样一个场景,你编写了一个"支付时金额计算"的函数,里面牵扯有一些打折、金额抹零的计算。
此时在正常的逻辑中你已跑通无误,但真实场景较为复杂,此时便自身简单功能验证(或不验证)便直接给测试人员进行验收。
此时基于以下2个现状 外加 无单元测试 的情况下:
我们最终上线的软件存在隐患的概率非常大。
假设真正上线后,出现了实际的金额计算bug,导致运维事故、甚至顾客投诉的出现,此时假设公司层面将责任100%划分给了测试人员,那笔者也就不多评价了。
绝大多数情况下,只要公司是明智的,其实编写者本身负有绝大多数的责任。
也就是说,出于自身技术工作素养,我们应该对软件质量应有足够的把控,不能依托于 测试人员来发现问题,更不能依托于上线后侥幸不出问题。
此时幻想下这个场景:你告诉领导,我2天可以做完,但是3天可以最大程度保质保量完成。
相信只要是有些产品意识的领导,相信都愿意等那一天。或者说,不等的话难道等着上线后试试看吗?
此时,单元测试就是 开发人员 的一项利器。
三、明确了必要性后,单元测试实践真正的阻力是什么?
都说没时间,那么给你时间,你真的能写好单元测试吗?覆盖率能够达到100%吗?
根据笔者听到的同行业朋友们的答复,以及应聘者们的答复,基本都是否定的答复。
也就是说,在笔者的认知里:没时间 = 找借口。
或者说单元测试函数的编写,以及被测函数的编写,是存在一定技术难度的。
笔者在这里重点分享一个概念:可测函数
笔者听到很多想尝试写单元测试的朋友的疑问都是,看着官方Demo挺简单(比如计算个加法、减法),都能看懂会写。
但是回到自己项目里发现,完全无从下手,例如以下Demo:
此时,一旦想对这个函数进行测试,会发现单元测试的脚本一旦引入这个被测文件,立即报错。
一方面数据库的连接信息报错,另一方面未知的其他业务js的引入报错。
也就是说,这个函数无法被测试,原因为 —— 外部依赖太多。
这里笔者引入一个老生常谈的概念 —— 反转依赖。
依赖反转/依赖倒置
例如以下简单的Demo程序:
也就是说,针对上述Demo程序最需要被测试的核心逻辑是 ★部分的逻辑,但是却不得不引入2个主逻辑无关的依赖函数,而2个依赖函数在这个函数中的作用仅仅是: ——在正确的时间点被触发
因此正向的依赖会导致测试用例寸步难行,改变就只能通过依赖反转,这并不是过于高深的理论,大家日常开发一定见过,例如以下Demo:
改造到此,已经是测试用例非常喜欢的函数形式了。
·通过传入不同的参数,来验证★号部分的主逻辑
· Mock入参中的onSuccess和onError函数
· 通过判断2个Mock函数被执行的次数,来验证执行成功与否。
也就是说:单元测试的顺利推进,可能更多的是对原始主逻辑编码的高标准要求。
四、最后再说两句
其实,如果说单元测试是为了不出错,也过于狭义了,单元测试还有很多更深远的意义,例如:
需求完成度:代码层面是否覆盖了全部的需求。
重构:"优化代码的时候产生了降级问题"这个是非常常见的现象,而有了单元测试,简直是重构的福音,开发者可随意改,只要原始N条单元测试依然可跑通。
否则永远是在试探,谁也不知道误碰了哪里。这里笔者也推荐一番TDD测试驱动开发,感兴趣的朋友们可以自行学习。
最后,笔者想再次强调下代码测试对于开发人员的重要性,如果开发人员对自己的产出无法有硬性的质量保障,而是依靠感觉和经验,其实是不合格的。
至于测试工作对于研发而言,有哪些可以做的工作,笔者后续会持续分享,例如大中小测试、自动化测试、压力测试等概念。