业务变化比较频繁，需要进行单测吗？
之前，我提到判断单测是否适用的几个维度，其中有一个就是业务变化情况。理论上来说，业务变化快，改单测成本高，维护成本也高。按理说，如果不是对功能质量有很高的要求，感觉是可以不写单测的。但事实真的是这样吗？针对这个问题，我与单测群的小伙伴们进行了讨论，大家都非常积极地发表了看法。从投票结果来看，有 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]
