单测真的没有作用吗？

工作了快 10 年了，跟研发小伙伴聊起单测，绝大多数人的反应是 —— 单测没啥用，写单测就是为了应付单测覆盖率的 KPI 指标。恰好我最近在团队落地单测相关的内容，经过一段时间的持续迭代，我对单测的看法也从一开始的 没啥用? 到后面的 好像有点东西?，再到最后的 卧槽，真牛逼！。基本上随着单测写得越深入，我对单测就越发重视。

为啥说单测没啥用？

那些说单测没啥用的小伙伴，我想大概率是不知道怎么写单测，没写过真正合格的单测，而只是用单测来凑凑单测覆盖率的 KPI 指标。在这种情况下，单测当然没啥用，因为它没办法帮你提高代码质量，帮你减少 bug。

试想一下，如果一个东西能帮你提升需求开发质量，减少提测需求 bug 数量，那研发同学怎么可能不愿意去学习一下呢？

在我看来，单测一个很明显的价值就是 —— 它能极大地减少你的需求 bug 数量，甚至一个 bug 都没有！ 那为啥大家都会觉得单测没用呢？我想问题可能是多方面的，其中可能的几个原因是：

1. 需求不明确，边写代码边改需求，这咋写单测？

2. 时间非常赶，业务代码都写不完，还写单测？

3. 不知道咋写单测，于是随便写写，发现好像没啥用？

4. 没有选择合适的单测框架，单测代码写的业务代码还多，这可咋整？

5. 等等

总而言之，这一切的原因导致没写出合格的单测，没办法让单测为他们带来好处，于是他们对单测充满了失望，最终就觉得单测没用。那怎么写出合格的单测呢？这就是另外一个话题了，有机会我们再详细聊聊。

单测到底有啥用？

听我瞎扯了半天，有同学忍不住了：看你把单测吹得，那你说单测到底有啥用？

在我看来，单测除了显著提升需求代码质量之外，还有下面几个好处：

1. 提升系统稳定性

2. 系统更加健壮

3. 提升代码编写能力

4. 有利于稳定迭代

5. 有利于深入了解技术与业务

提升系统稳定性。 如果你每一个方法函数都经过了测试，并且其分支覆盖率都达到了较高水平，那么你很难写出有问题的代码，因为每种情况你都考虑到了。

在后续的迭代中，由于单测用例的存在，它就可以保证修改后的代码不会影响到之前的业务逻辑。简单来说，由于单测的存在，违背之前业务逻辑的代码无法运行通过，因此提高了系统稳定性。

系统更加健壮。 系统的健壮，其实是得通过分支覆盖率来实现的。分支覆盖率，其实就是每一种可能的情况你都考虑到了，那么系统会更加健壮。

举一个很简单的例子，有一个计算器类的除法函数，简单的测试可能只会用正数进行测试，更进一步的可能会用负数，但是如果用 0 去测试呢？是否能成功呢？通过对分支覆盖率的要求，使得我们考虑到更多异常情况，从而使得系统更加健壮。

提升代码编写能力。 当我们开始对单测覆盖率和分支覆盖率有要求，并且开始写单测代码之后，我们会被迫站在另一个视角去审视我们写的代码。如果我们的代码写得一点逻辑都没有，那我们的单测会很难写，那我们会忍不住去重写它，这就间接地提升了我们的代码编写能力。

与代码逻辑类似，代码的结构以及设计也会影响单测的编写，写单测可以让我们重新审视自己写的的代码，从而间接提升我们的代码编写能力。

有利于稳定迭代。 如果你写的代码质量很高，只有非常少的 bug，甚至一个 bug 都没有。那么测你需求的测试肯定很开心，因为直接一把过呀！从项目管理层面来看，如果每个人都能做到这样的程度，那么项目的迭代是非常稳定、并且高效的！

有利于深入了解技术与业务。 当我们写单测的时候，我们必须去了解某个东西是怎么运行的。如果你没有了解清楚某块业务，就开始去修改这块业务的代码，那之前的单测用例会教你做人，频频报错的单测信息会让你寸步难行。

单测用例的存在让你必须弄清楚这块业务的逻辑，才可以写新的业务逻辑，这间接促进了我们对于业务的了解。此外，我们写单测的时候经常会进行 Stub 和 Mock，这会要求你必须弄清楚项目中用到的技术原理，不然你无法成功编写单测代码，这也同样间接促进你去了解项目中用到的技术。

单测不是银弹

说了这么多，可能有些小伙伴觉得我是单测的死忠粉。但我想说的是：单测也不是银弹！

在我看来，单测只能解决一类问题，那就是 —— 你觉得你写对了，但是你没写对的问题。 对于那些你本来就不知道，或者说代码里根本就没写的东西，单测是无能为力的。举个很简单的几个例子：

提测提了一个 bug，你排查之后发现有某个业务细节你没考虑到，从而触发了这个 bug。由于你本来就没考虑到，因此代码里也没有做对应的处理，那么单测肯定也解决不了这个问题。

由于产品对需求没有写清楚，于是在测试阶段不断补需求细节，于是你也不断地修修改改，于是越改 bug 越多。

除此之外，写单测也确实是会费一些时间，特别是对于刚刚写单测的同学来说。如果一个项目非常紧张，需求也不确定，经常边写代码边改需求，这时候再要求单测覆盖率，可能不太现实。

单测的适用场景

看了这么多，知道了单测有那么多好处，但又单测又不能包治百病，那单测到底适合在什么场景使用呢？在我看来，对于是否要推行单测，以及单测的要求高低，其实取决于下面几个维度：

1. 代码复用率。代码复用率越高，越有必要推行单测，越有必要提升单测的要求。因此这些代码被很多业务引用，因此其一旦有问题便会影响很多业务方，在这样的代码推行单测是收益较高的。

2. 业务变化率。业务变化越快，越不适合用单测。如果业务变化非常快，一个单测的内容上线了没几天就又要修改，那么你不仅仅需要修改业务代码，还需要修改单测代码，那就是双倍的工作量了。

3. 人员变化率。人员变化率指的是某个模块负责人的变化情况。如果某个模块的负责人经常变来变去，那么也是不太适合推行单测的。因为新负责的人需要花大量的时间去熟悉单测的内容，这会导致需求开发的时间变得非常长。

4. 业务重要性。越是核心的业务，越有必要推行单测，并且越有必要以高标准要求。因为核心业务的稳定性、健壮性对于公司来说肯定非常重要，而单测确实是能够在最小单元去提升系统稳定性和系统健壮性。

上面提到的 4 个衡量维度，我们不能单一地去看待，而是要根据实际情况去综合判断。例如某个业务的人员变化就是很频繁，那就一定不适合推行单测吗？

其实并不是，而是说对于人员变化非常频繁的业务，其推行单测成本会很高。但如果这块业务就是非常重要，但他的人员变化就是很频繁，那强制以高标准的单测要求确实可以提高系统健壮性和系统稳定性，但是代价就是研发时间很长。如果产研团队能够接受这个结果，那么这么做就是合理的。

总的来看，是否推行单测以及推行单测的标准高低，需要我们根据上面几个维度去综合考量，得出一个最适合的标准！

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取