研发效能工程实践-单元测试

什么是单元测试

什么叫单元测试呢？可以拆分成两个词“单元”和“测试”，“单元”通常我们可以理解为最小独立模块，在编程中可以是我们代码中的一个函数、一个类或是一个模块；“测试”就很好理解了，就是对一个函数、类或模块做正确性验证。注意单元测试都是针对系统内部的测试，它不会跨系统。单元测试提现在测试对象小，测试执行时间短，测试结果稳定。
单元测试应该满足以下几个要求

• 单元测试中不应该有远程调用。比如说我在单元测试中发起网络调用去互联网获取一个资源然后执行后续测试。如果你在你的单元测试中写了这样的逻辑，你可能在本地执行OK的，但是提交代码跑流水线时，跑流水线的机器可能根本不能访问外网，那么你的单元测试将失败。即使可以访问外网，那么这个过程也会很慢，违背了我们单元测试的初衷，单元测试应该是快速执行的。你可能会说那我代码逻辑要查询数据库等应用怎么办？放心你能想到的所有依赖，前辈们早就有解决方案，我们将在后文中讲解如何编写这类单元测试
• 不应该依赖本地环境。比如，你不能在单元测试中读取本地机器的环境变量，你的单元测试应该要保证在任何机器上都可以成功执行

单元测试必要性

在开篇中我们讨论过单元测试的必要性，我在这里还是想再说一次。我敢肯定市面上绝大部分的小公司以及某些大公司都没有编写单元测试的习惯，特别是一些相对比较传统的行业。互联网公司在单元测试编写上相对来说要好一些，因为大家可能都喜欢以google、facebook等知名互联网公司为榜样，乐意学习他们的工程实践方法。

单元测试可以有效减小研发成本

从图中可以看出，一个问题测试发现阶段越晚，那么它的反馈周期就越长，且修复它的成本就会越高，这条曲线近乎是指数函数。
这个是很容易理解，比如一个问题如果单元测试中暴露出，那么修复它只需要开发人员随手就可以修改，因为这个阶段还是停留在开发阶段；如果一个问题是由测试人员发现，不仅增加了测试人员的成本，还会增加后续测试人员与开发人员沟通确认的成本；如果是由最终用户发现问题，那么这就是一个线上故障，它的反馈周期更长，修复它之后需要走发布流程，如果是终端APP，那么修复它的成本将更高，因为如果这个问题是致命的，你可能需要用户终端APP强制升级，非常影响用户体验，可能导致用户流失。

单元测试可以保证代码重构正确性

为什么很多团队代码的“屎山”越来越大，导致团队技术债越来越多，究其原因就是团队只管开发新代码，而不重构历史代码，今天你加一个if，明天我加一个else if，长此以往，代码变得越来越难维护。
我自己也经历过，我曾经在一些项目开发中，看见别人的函数大致可以实现我的功能，但是我需要改一些地方，但是我不敢动别人的代码，除非我百分百确定那样改了没问题，不然可能就要出问题。是什么导致我们不敢轻易动别人代码呢？最大的阻碍就是可能我改了别人的一段代码，无法保证调用了这个函数的其他业务逻辑不会出问题，为了保证不出问题，你可能需要去将调用这个函数的所有业务逻辑都看一遍，这个成本可能已经远远高于你重新编写一个新函数。
最终你可能默默的把这个函数复制粘贴一遍，然后方法名加上v2以满足你的功能需求，长此以往我们就可能在代码中看见很多功能类似的代码，团队的其他开发者可能也很难搞清楚它们之间的关系，这个时候技术债就产生了，如果不解决这些问题，后续的维护将变得越来越困难。当然还有其他很多的问题会导致技术债产生。
一个很好的解决办法就是单元测试+重构，如果项目一开始代码就编写了完善的单元测试，那么后续的开发者可以在适当的时候重构它，重构完后只需要执行单元测试就知道自己的重构是否影响了整个业务逻辑，这样就可以持续让代码保持在一种健康的状态。

如何编写单元测试

接下来将简单介绍如何在日常开发中编写单元测试