前言
哈喽,大家好,我是海怪。
最近在组里我又领了一个新任务:前端单元测试。
关于这个话题在很早的时候就想和大家聊了,奈何一直没机会。对于我个人来说,我是非常喜欢写单测的。最近还买了本《软件测试》的书,算是再次复习一下大学时学过的专业课,平时在捣鼓一些个人项目的时候也会做一些基础的单测。
一谈到单测,可能大家的第一反应都是敬而远之。
没啥用,没时间,我不会
我承认写单测是个非常有挑战性,且难度不小的活,但 我依然推荐大家尝试去写一写单元测试,因为它所带来的好处不仅仅是大家想的那么简单:“只是 Bug 少了一点”。 所以,今天我会尝试从另外一些角度来讨论单测可以给我们带来哪些好处。
优化流程
接着刚刚说到的 “只是 Bug 少一点” 这句话,可能大多数觉得单测就是在提测前减少一点 Bug 而已:
这样的想法确实是最直观的。但这只是想到了第一层,如果我们把 开发流程所有步骤 都加进来,会发现是这样的:
在 开发过程
后面,几乎每个流程都可能抛出 Bug。越是到后面流程才抛出的 Bug,程序员就越是要投入比开发阶段更大的时间和业务,而且所承受的风险也是最高的。
或许大家会想:不就改个 Bug,改几行而已。 可是大家有没有想过在跟测的过程中,很可能你已经开始另一个需求的评审了! 此时的你在解决突然插入的 Bug 的时候,心态还会像刚开始写代码时候那么轻松么?
实际上,还有更多的隐性成本没有考虑,比如反复确认产品逻辑、反复确认交互设计、反复确认前后端接口设计、各端对产品的理解。 有的时候,你就会发现这样很魔幻的场景:明明是一个字段的展示问题,竟然要花上一上午,拉了 4、5 个人来开会核对的情况。
下面这张图,也在说明两个问题:一是 85% 的缺陷都在代码设计阶段产生;二是发现 Bug 的阶段越靠后,耗费成本就越高,呈指数级别的增长。这种 “指数成本” 的案例也经常发生,当我们改正一个 Bug 的时候,可能随之而来又会多出 3 个 Bug,俗称:改崩了。
所以,在早期的单元测试就能发现bug,不仅可以省时省力,在开发流程上提高效率,也能降低反复修改出现的风险和时间成本。
保证质量
这一节主题就是大家经常想的:减少 Bug 率。我们不妨来想一个问题:什么才是 Bug? 相信所有开发人员都不愿意写 Bug,在 《软件测试》 这本书中将 Bug 描述成 “软件缺陷”,里面说道:
大多数的 “软件缺陷” 并非源自编程错误,对众多从小到大的项目进行研究而得出的结论往往是一致的,导致软件缺陷最大的原因是产品说明书!见下图
大多数的产品还是能够写出一份清晰明了的需求单的,奈何 ta 也不可能把所有情况想都枚举出来,这也导致了开发时很容易出现考虑不周全的情况。往往能够发现异常情况的人要么是测试、要么是交互视觉、要么是后期产品体验。 那到这个时候才发现的问题,然后再去修复又会出现的 指数爆炸的成本。
如果把实现功能看成走迷宫,把找到通路看成上线需求, 那么编码实现的过程就像从入口找出口