为什么要单元测试？

背景

我们在日常开发中经常发生开发完成的东西，在开发的时候看似没有问题，但是到了SIT/UAT 的时候问题不断涌现，导致我们需要花费很多时间去查看问题和重新测试，浪费了大量的时间。

解决方案 - 单元测试

UT （Unit Test）为单元测试，开发人员在每次开发完一个方法或者功能是，需要自己考虑好当前方法有哪些使用场景，并通过单元测试的方式验证输入输出是否符合预设的逻辑，确保开发的东西是正确的。

那么开发需要进行单元测试呢？

1. 提高开发人员的代码质量
2. 理清和优化代码逻辑
3. 降低项目风险

提高开发人员的代码质量

如果开发人员每次开发完成后都进行对应的单元测试，那么就能确保方法在使用上的正确性。如果在测试过程中发现了问题，那么也可以在小范围内及时定位到问题，会比在系统性联调的时候在整个系统中定位问题要高效很多。

理清和优化代码逻辑

在单元测试之前，开发人员需要根据自己的代码功能进行思考当前方法有哪些应用场景，需要用来做什么，针对这类场景需要哪些输入与输出的验证。在思考的过程中就相当于再次梳理需求和自己的开发思路是否匹配，如果不匹配也可以及时的做修改，不必等到整体的继承测试时才发现该部分的代码不符合需求或者存在缺陷。

降低项目风险

经过单元测试的代码，代码的健壮性有所提升，那么出错的概率降低，项目在代码缺陷上所需要花费的时间就会相应的减少。同时，代码质量的提升，代码缺陷造成的技术债务降低，也能够提升后期运维的效率。

对开发人员的好处

开发人员通过单元测试，能够让自己更加理解功能需求，增强代码逻辑，提高开发质量。促使整体的业务能力，工作效率，交付能力均有所提升！

不做单元测试的坏处

我们在项目中经常会遇到不做单元测试的开发，当我们和这类开发人员进行合作时，经常遇到下面三个问题

1. 系统对接时出错
2. SIT/UAT 时代码缺陷频出
3. 整体项目进度推迟或频繁赶进度

由于我们无法保证每个开发提交的未测试的代码的准确性，如果每次都在系统对接或者SIT/UAT中让测试人员进行测试，那么会面临时间上的极度浪费，我们可以来简单比较一下没有单元测试和有单元测试的区别。

我们暂时按照每个阶段的时间消耗标准均为 1 来比较，实际的项目中我们根据不同的业务场景会有不同的时间比例，这里就不做赘述。

这里的花费时间指代的是同一个问题在DEV/SIT/UAT 发现时所需要使用的时间成本

接下来我们根据不同的情况对比结果

从上表的实际场景中我们可以发现，问题能够越早发现，则整体的时间消耗会越少。

这里我们假定所有成员能够第一时间处理问题的情况下时间的损耗，但是在我们实际情况中，同一个问题能够限制在越小的范围处理，那么处理的效率则越高，如果涉及到多方的参与，中间的交流，等待确认，循环往复等情况也会增加成本的损耗，风险在不断的增加。

因此单元测试在开发中是重要的一环！