lsekfe 发表于 2023-3-20 14:14:54

业务变化比较频繁,需要进行单测吗?

之前,我提到判断单测是否适用的几个维度,其中有一个就是业务变化情况。理论上来说,业务变化快,改单测成本高,维护成本也高。按理说,如果不是对功能质量有很高的要求,感觉是可以不写单测的。
  但事实真的是这样吗?针对这个问题,我与单测群的小伙伴们进行了讨论,大家都非常积极地发表了看法。从投票结果来看,有 50% 的人觉得没必要,有 50% 的人觉得有必要。
http://www.51testing.com/attachments/2023/03/15326880_202303171457011okhU.jpg
  笔者一开始是觉得可以不写的。毕竟如果一个业务经常变化,那么你就要不断地去调整单测的内容,这样势必会增加研发成本,最后造成研发交付周期变长。从群里小伙伴的投票来看,应该有不少小伙伴跟我持同样的看法。
  但是当我深入去思考这个问题时,我却得出了完全不同的结论 —— 即使业务变化快,也需要坚持写单测!
  站在整个软件产品来说,两个非常重要的维度是:交付速度和交付质量。就如我上面所说:我们不写单测的原因,是因为单测会拉长交付周期,使得交付速度变慢。但如果交付速度提高了,可是交付质量下降了,可以接受吗?
  我想,对于有些规模的公司来说,交付质量一定比交付速度更重要。而对于一些小微或者创新业务来说,可能交付质量可以没那么重要,但是也不能太过于拉垮。因此,是否写单测这个问题,本质上是交付速度和交付质量哪个更重要的问题。
  但我们要知道 —— 上面的分析其实是站在整个产品(老板)的角度去思考问题的。如果我们站在编程者的角度看,你现在不写单测,很可能只是把现在写单测的时间挪到后面修 bug 而已。
  除非你的代码质量真的很高,高到及时不写单测一个 bug 都没有,那确实没必要写单测了。不然就如群友所说 —— 「前面埋下的雷,总会炸到修 Bug 的人」、「流程越往后,排查和修复 bug 的成本会急剧增加!」。
http://www.51testing.com/attachments/2023/03/15326880_202303171457071zkkD.jpg
  除此之外,写单测不仅仅能降低你的 bug 数量,它还能让你考虑逻辑更加全面,让你写代码的时候对各个异常、特殊分支都考虑到位。这其实是一种习惯,它会持续地让你迭代优化自己的代码质量,从而让你不断提升。
  从觉得单测没啥用,到觉得单测还有点用,再到业务变化不大可以写写单测,最后到即使业务变化快也要写单测,深感单测写得越多,越能感觉到单测的好处。?

页: [1]
查看完整版本: 业务变化比较频繁,需要进行单测吗?