本文已参与掘金创作者训练营第三期「高产更文」赛道

1. 什么事是单元测试？

单元测试（Unit Test）,是指对软件中的最小可测试单元进行检查和验证（来自百度百科）。概念里值得注意的是，最下可测试单元的理解，可以是一个或者多个分支、可以是一个函数，一个类，但是再大的恐怕放到单元测试中就不太合适了，这个也是场景的单测的误区之一。

2. 为什么要做单元测试？

对于相对稳定的系统（比如：一些非常底层的系统，很少大规模迭代），如果单测覆盖率非常高，基本可以达到比较理想的CI/CD，甚至是无需QA参与(事实上，有些大厂的某些团队，UT代码行覆盖率90%，只需要1个QA)。

测试成本与发现bug的时机成正比，bug发现越晚测试成本越高。单元测试时测试左移的利器，如果有了单元测试能够拦一道，对于QA理想情况下（认为UT覆盖代码行都测试有效的情况下），测试人员完全可以节约出精力，放到系统和全局的测试中。

很多研发同学在写单测过程中发现，这个代码本身根本无法下手写单测，有的是巨型函数，动辄3-500行，有些是深深的依赖关系，写单测无从下手等。解决的方法，一定会让这个同学去反思，这样的函数活着，究竟是为了什么。

实际经验告诉我们，如果有一套代码，你想快速上手，除了不一定更新及时的文档，最灵魂的就是单测，单测告诉了我们如何使用，单测告诉了我们它实现的是什么功能。比文档好用100倍，因此，单测，即文档。

好的，我知道大家对单测的好处如数家珍，但是实际情况是项目迭代太快，需求都做不过来，单测确实不是适合每个团队在任何阶段都下手的，我认为该考虑去做单测，有以下几个时机：