单元测试理解

最近一段时间跟朋友沟通到单元测试的问题，朋友吐槽公司技术大佬对于单元测试完全是不接受状态，质量工作完全由测试人员通过UI自动化、手工黑盒测试完成，导致测试人员异常痛苦，每次开发人员交付的代码几乎接近不可运行状态。

我最近也就单元测试咨询了一些技术大佬的看法，加上对我参与、了解的所有团队单元测试做法的回顾。发现对于不同的团队、不同的技术背景，对于单元测试的认同度、测试策略都是不相同的（有完全认为没有必要浪费时间的、有非常认同要求单测覆盖率达到90%并且要求单测必过的）。简单整理一下个人对于单元测试的认知和看法。

1. 什么是单元测试

百度词条解释，单元测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

我觉得大家对它有不同的认知和看法的主要原因是这个最小单元到底怎么定义？代码层面的一个函数、一个类、业务层面的一个功能逻辑、一个接口？

我认为首先需要对单元测试进行分层

• 基础代码层即为公共函数（编码过程中解耦出的公共方法，与业务无关用于代码实现），当然它可以是一个函数也可以是一个类，这取决于你的编程方式。
• 业务代码层即为处理业务逻辑的代码，它即包括业务逻辑处理的函数，也包括所有对外开放的接口

应对不同的层次需要使用不同的方式，例如我认为基础代码层（即公共函数）一定要进行单元测试，业务代码层可以根据团队情况选择只做业务接口测试、还是全部都进行测试覆盖（业务接口基本可间接覆盖所有业务代码）。

另外单元测试也不仅是后端需要，前端也是有需要进行单元测试的，前端也有大量的公共组建、公共方法、逻辑处理。

2. 单元测试与其他测试有什么区别

我理解的测试阶段包括：单元测试、集成测试、端到端测试。

• 单元测试包括：基础代码函数测试、业务代码函数测试、单元级接口测试。
  单元测试，测试对象是单一服务。
  这里单元级别接口测试与集成测试的接口测试有何不同，单元级接口测试需要将所有需要用到的外部服务mock（数据库、其他服务、第三方系统等），将测试对象限定在当前单一服务代码上，仅测试当前服务代码的处理。
• 集成测试包括：接口测试、UI测试
  集成测试，即当前项目内的所有服务集成，测试对象是当前项目。
  接口测试为后端集成，需要mock所有第三方系统，将测试对象限定在所有当前项目代码上，包括了代码、数据库等内部服务；UI测试为前后端集成，在接口测试的基础上，对前端代码、服务进行测试。
• 端到端测试包括：接口测试、UI测试
  端到端测试，即当前项目所属业务的端到端，测试对象是当前业务。
  端到端接口测试为后端测试，不需要mock任何第三方系统，将测试对象限定在业务上，包括了代码、数据库、相互依赖的第三方服务等；UI测试为前端测试，在接口测试基础上，对前端代码、服务、相互依赖的第三方服务等。

3. 单元测试的优点、缺点

单元测试有优点：

• 可以快速debug，发现问题所在
• 有利于培养编写人员的测试能力
• 对于代码的修改维护，提供一层保障
• 利于代码的解耦，和代码的整洁。当复杂函数有多个测试点时，为了满足单元测试的需要需要对函数进行解耦、更好的封装，这无疑不是对于解耦和提高代码整洁度的好方法。

当然单元测试也有缺点：

• 降低了开发效率，需要思考测试方法，需要实现各种mock
• 有一定的维护成本，代码发生修改时，单元测试代码也需要同步维护

对于单元测试的使用，需要参考它的优缺点，不能完全膜拜，也不能完全否定

4. 单元测试要不要做

其实从单元测试与其他测试区别分析就可以看出，理论上端到端测试可以完全覆盖所有测试，那单元测试还有没有必要做呢？
我认为有必要并且非常有必要，为什么？

• 端到端测试理论上可以完全覆盖所有测试，但是端到端测试只能在所有开发、集成、部署之后才可以进行测试，此时进行测试一是测试不稳定，任何改动都会造成端到端测试的修改；二是debug难度大，发现问题需要逐一逐层分析原因实在浪费时间。
• 而单元测试可以在未部署、集成状态下就可以测试发现问题，debug时极快的定位问题所在。单元测试后在通过集成测试、端到端测试完成其他服务的测试，出现问题时，如果单元测试没有问题，就可以快速定位问题至其他服务上。
• 质量责任分摊，整个团队都需要对项目质量负责（大多团队仍然存在测试团队完全负责质量的现象，这个问题可以阅读敏捷开发&质量管理），每个人都对质量负责的效果是不是比只有一波人负责来的好？每个人都对自己的工作负责，项目质量不是会更高？

5. 单元测试由谁来做比较好

单元测试有谁来做比较好，我认为开发来做比较好。为什么说开发来做最好？（当然介于种种原因公司有单独负责单元测试的团队也是可以的）

• 代码是开发完成的，代码发生任何修改时，开发人员很快就能知道修改了哪些内容，从而对单元测试同步进行修改。如果由其他团队或人进行修改的话，需要大量的沟通成本。
• 单元测试的编写可以培养开发人员自测的意识，增强开发人员的能力。
• 单元测试的编写可以让开发人员更多的了解业务逻辑，以及可以培养开发人员应对业务优化代码的想法，而不是一个单纯的编码机器，工厂式的编码方式并不是长远发展方式。
• 团队工作责任，开发人员有责任保证自己的工作输出，对自己的工作验证是很有必要的。

6. 单元测试策略怎么制定

单元测试策略的制定并不是一概而论的，不同的团队就需要不同的策略方法。

• 例如互联网项目，开发周期短工作量大。单元测试可以优先覆盖基础代码层，对于业务层可以优先覆盖单元级接口测试，业务代码函数可以慢慢补充。
• 例如非互联网项目，开发周期相对较长。单元测试可以优先从基础代码层、业务代码函数开始。由于集成较晚，单元级接口测试可以放在最后进行。

但是有一点个人认为，无论是否是互联网项目，单元测试越高的覆盖率对于质量保证支持越高，可以慢慢补充、但不可以不做。

7. 单元测试覆盖率怎么统计

单元测试其实已经有着丰富的工具，支持编写、执行、统计，例如：

• nodejs的jest
• golang的go test、gometalinter
• python的coverage
• 等等

很多团队的做法是将单元测试的统计集成在sonar中没完成静态代码的扫描和统计，可以参考Sonar与代码检测分析

8. 对于TDD的看法

我见到有很多团队实力推荐TDD（测试驱动开发），也有很多团队拒绝TDD。

我个人认为TDD是一种很好的开发方法，先整理业务场景和测试点，然后根据业务场景和测试点进行编码。这种方式大大的增强了开发人员对于业务的理解，对于减少bug的有着极大的帮助。

但是很多团队拒绝的原因也很明显，太消耗时间，需要开发梳理各种业务场景、测试点。

对于梳理业务过于消耗时间这件事，我认为是团队资源的未充分利用和严重的“深井病”。为什么这样说，梳理业务场景有没有发现这件事情产品经理、测试人员都在做，产品经理梳理用户旅程、测试人员在此基础上帮助丰富各种业务场景，既然有人做了这件事为什么不能直接拿来用呢？

产品经理输出用户旅程后，开发人员通过设计后进行业务happy path进行开发，当测试人员帮助梳理出更丰富的无场景之后，开发人员参考进行单元测试的补充和异常场景的开发，是不是可以极大的利用资源、缩短消耗时间？