聊一聊单元测试的ROI问题_单元测试的roi怎么说

在读者评论中，点赞最高的一条是关于单测ROI的：

和平常与开发同学交流的情况一样，关于单测大家最关心的问题毫无疑问是ROI。毕竟，单测是需要开发同学投入宝贵时间去做的，是需要和他们手头上众多事情争抢时间的。

如果大家感受到的单测ROI不高，那么单测这件事情是坚持不下去的。同理，如果大家觉得单测ROI还可以，那么他们会主动把这件事情做下去。

那么，单测的ROI问题到底如何？做单测到底值不值？我觉得，这个问题无法笼统来回答。

原则上，我反对唯单测论，反对针对任何代码都无脑做单测，反对盲目追求100%的单测覆盖率。实践上，我认为应该具体问题、具体分析。是否做单测、单测做到什么程度，应该取决于被测代码的特征，这是最根本的决定因素。

我的核心观点是：单测的成本与被测代码的依赖复杂度成正比，收益与被测代码的逻辑复杂度成正比。

• 依赖复杂度：表示被测代码与其他代码的依赖程度。依赖复杂度越高，我们做单测时的Mock成本就越高，单测用例也很脆弱，容易受依赖的变化而失败，维护成本也越高。

• 逻辑复杂度：表示被测代码内部逻辑的复杂程度。逻辑复杂度高，意味着代码中的分支多、业务规则多、计算步骤多，针对这部分代码做单测，再合适不过了。

基于这个观点，我们将被测代码分为四种类型，每种类型代码有着不同的单测ROI，应该采用不同的测试策略。如下图所示：

• 灰色区域代码：代码逻辑复杂度低、依赖复杂度低。这部分代码风险低，只需要简单测试即可，做不做单测其实问题不大。

• 绿色区域代码：代码逻辑复杂度高、依赖复杂度低。这部分代码单测投入低、收益高，ROI很高，非常适合做单测，甚至只有单测才能把这种代码测好。试想，如果代码中有一堆if、else处理逻辑，如何通过集成测试、E2E测试去覆盖？那样不仅效率低，而且很难保证覆盖全面。

• 黄色区域代码：代码逻辑复杂度低、依赖复杂度高。这部分代码非常适合也应该使用“集成”测试去覆盖。注意这里的“集成测试”是打引号的，是广义的集成测试，包括了针对多个类的单测。针对这部分代码，测试的重心应该是依赖关系，即契约。将被测代码与它的依赖代码放在一起进行测试，显然是更好的选择。

• 橙色区域代码：代码的逻辑复杂度高、依赖复杂度也高。这部分代码是典型的违反了“低内聚、高耦合”设计理念的代码，也是可测性非常不好的代码。很多历史遗留代码就属于这种，针对这些代码编写单测用例困难重重，导致大家对单测望而却步。这种情况，首先需要解决的不是单测问题，而是可测性问题。因此根本出路在于代码重构，单测应当在重构过程中及重构完成后发挥作用。

最后：下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。