单元测试规范和实践

1、软件测试的分类

软件测试按照阶段划分，一般可以分为如下四类：

单元测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：函数。常常由开发人员依据详细的设计文档进行测试，包含接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试等。总的来说，单元测试主要是测试程序员自己编写的代码逻辑的正确性，并非是端到端的集成测试，它不需要测试所依赖的外部系统的逻辑正确性。所以，如果代码中依赖了外部系统或者不可控组件，比如，需要依赖数据库、网络通信、文件系统等，那我们就需要将被测试代码与外部系统解依赖，而这种解依赖的方法就叫作"mock"。所谓的 mock 就是用一个"假"的服务替换真正的服务，mock 的服务完全在我们的控制之下，模拟输出我们想要的数据。

集成测试

将模块接口采用适当的集成策略组装起来，对模块的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查模块之间的接口是否正确。一般单元测试之后进行，主要测试模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响。

系统测试

包括对功能、性能以及软件所运行的软硬件环境进行测试。包括回归测试和冒烟测试，测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等。

验收测试

目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买者展示该软件系统满足原始需求。这个阶段主要是依据用户的需求和验收标准来测的，由用户进行测试，测试所有的功能是否符合他们的预期等等。

不同点

下面这个表格详细展示了单元测试、集成测试、系统测试和验收测试的区别：
单元测试集成测试系统测试验收测试编写人员开发开发开发/测试产品编写场地生产代码仓库内生产代码仓库内生产代码仓库内/生产代码仓库外生产代码仓库外编写时间代码发布前代码发布前代码发布前/代码发布后代码发布后编写成本低中高高编写难度低中高高反馈速度极快，秒级较慢，分钟级慢，天级别慢，天级别覆盖面积代码行覆盖>=80%功能级别覆盖 HappyPath核心保障链路核心保障链路环境依赖代码级别，不依赖环境依赖日常或本地环境预发或生产环境提测环境、预发、生产环境外部依赖模拟全部模拟部分模拟不模拟，完全使用不模拟，完全使用

2、单元测试规范

1）【强制】好的单元测试必须遵守 AIR 原则。

说明：单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。

A：Automatic（自动化）
I：Independent（独立性）
R：Repeatable（可重复）

2）【强制】单元测试应该是全自动执行的，并且非交互式的。测试框架通常是定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用 System.out 来进行人肉验证，必须使用 assert 来验证。

3）【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。

反例：method2 需要依赖 method1 的执行，将执行结果做为 method2 的输入。

4）【强制】单元测试是可以重复执行的，不能受到外界环境的影响。

说明：单元测试通常会被放到持续集成中，每次有代码 check in 时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。

正例：为了不受外界环境影响，要求设计代码时就把 SUT 的依赖改成注入，在测试时用spring这样的 DI 框架注入一个本地（内存）实现或者 Mock 实现。

5）【强制】对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别。

说明：只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域。

6）【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。

说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。

7）【强制】单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下。

说明：源码构建时会跳过此目录，而单元测试框架默认是扫描此目录。

8）【推荐】单元测试的基本目标：语句覆盖率达到80%。

说明：在MVC分层中的 DAO 层，可重用度高的 Service，都应该进行单元测试。

9）【推荐】编写单元测试代码遵守 BCDE 原则，以保证被测试模块的交付质量。

B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
C：Correct，正确的输入，并得到预期的结果。
D：Design，与设计文档相结合，来编写单元测试。
E：Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果。

10）【推荐】针对 private 方法，不单独写单元测试，应该依赖 public 方法的单测去调用。

11）【推荐】对于不可测的代码建议做必要的重构，使代码变得可测，避免为了达到测试要求而书写不规范测试代码。

12）【推荐】在设计评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好覆盖所有测试用例（UC）。

13）【推荐】单元测试作为一种质量保障手段，不建议项目发布后补充单元测试用例，建议在项目提测前完成单元测试。

14）【参考】为了更方便地进行单元测试，业务代码应避免以下情况：

构造方法中做的事情过多。
存在过多的全局变量和静态方法。
存在过多的外部依赖。
存在过多的条件语句。
使用复杂的继承关系。

说明：多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。

3、最佳实践

采用 Mockito 框架，不采用其他框架，已经使用 PowerMock 等其他框架的单测代码保留不变或者自行修改。我们注意到，Mockito 框架在持续更新，PowerMock 最新的版本停在了是2020年11月份。

Mockito 推荐使用4.x版本，Mockito4要求jdk最低为jdk8，Mockito5最低要求为jdk11。

采用 JUint4 框架。

3.1、引入 Mockito和 Spring Test 依赖

在pom.xml文件中加入下列依赖：

<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-core</artifactId>
  <version>4.8.0</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test</artifactId>
  <scope>test</scope>
</dependency>

3.2、一个简要的测试样例

下面列举简单的service写法：

publicclassUnitServiceImplimplementsUnitService{@AutowiredprivateUnitDao unitDao;@OverridepublicStringsayHello(){Integer delete = unitDao.delete(1L);System.out.println(delete);return"hello unit";}}

对应的测试类如下：

@RunWith(MockitoJUnitRunner.class)//  不允许使用 @SpringBootTestpublicclassUnitServiceImplTest{@MockprivateUnitDao unitDao;// mock数据访问层对象@InjectMocksprivateUnitServiceImpl unitService;// mock被测试对象@TestpublicvoidunitTest(){// mock 调用unitDaowhen(unitDao.delete(anyLong())).thenReturn(1);// 使用assert判断结果Assert.assertEquals("hello unit", unitService.sayHello());}}