单元测试规范和实践-Toy模板网

这篇具有很好参考价值的文章主要介绍了单元测试规范和实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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写法：

public class UnitServiceImpl implements UnitService {

  @Autowired
  private UnitDao unitDao;
  
  @Override
  public String sayHello() {
    Integer delete = unitDao.delete(1L);
    System.out.println(delete);
    return "hello unit";
  }
}

对应的测试类如下：文章来源地址https://www.toymoban.com/news/detail-790348.html

@RunWith(MockitoJUnitRunner.class)  //  不允许使用 @SpringBootTest
public class UnitServiceImplTest {

  @Mock
  private UnitDao unitDao;  // mock数据访问层对象

  @InjectMocks
  private UnitServiceImpl unitService;  // mock被测试对象

  @Test
  public void unitTest() {
    // mock 调用unitDao
    when(unitDao.delete(anyLong())).thenReturn(1);
    // 使用assert判断结果
    Assert.assertEquals("hello unit", unitService.sayHello());
  }
}