作为一个程序员，之前一直没有重点关注过单元测试相关的东西，真心惭愧；最近由于工作原因恶补了很多知识，收获不小；学习嘛，主要还是要肯花时间；
文中代码已上传到： https://gitee.com/aqu415/demo/tree/master/mockito
相关概念
- 单元测试
单元测试即对单个方法内部逻辑的测试，不涉及关联其他分层的代码逻辑测试；
比如定义一个UserService,一个UserDao分别有一个save方法，并且前者在方法内部调用后者方法；
那么对UserService的save方法进行单元测试即是userService方法内部逻辑测试，应该要屏蔽掉UserDao相关方法调用返回值影响；
单元测试的特点：不应依赖容器（如spring容器），执行速度快
- 集成测试
集成测试恰好与单元测试相反，它需要将关联类的行为纳入测试结果，
便于测试系统各个组件集成后是否能运行正确；
- maven生命周期之deploy
如果开发中依赖maven作为构建工具，则可以关注下maven定义的一个生命周期（以deploy为例）
- 各阶段描述
| 阶段 | 处理 | 描述 |
|---|---|---|
| 验证 | validate | 验证项目 验证项目是否正确且所有必须信息是可用的 |
| 编译 | compile | 执行编译 源代码编译在此阶段完成 |
| 测试 | Test | 测试 使用适当的单元测试框架（例如JUnit）运行测试。 |
| 包装 | package | 打包 创建JAR/WAR包如在 pom.xml 中定义提及的包 |
| 检查 | verify | 检查 对集成测试的结果进行检查，以保证质量达标 |
| 安装 | install | 安装 安装打包的项目到本地仓库，以供其他项目使用 |
| 部署 | deploy | 部署 拷贝最终的工程包到远程仓库中，以共享给其他开发人员和工程 |
进入正题，我这里使用的打桩框架是Mockito
Mock
Mock即打桩，理解成预设方法的返回值
依赖（POM配置）
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-junit-jupiter</artifactId>
<version>3.1.0</version>
<scope>test</scope>
</dependency>
测试代码
写两个类 AService,BService
package com.xx;
public class AService {
BService bService;
public String test() {
return bService.btest();
}
}
package com.xx;
public class BService {
public String btest() {
return "bb";
}
}
测试类
package com.xxx;
import com.xx.AService;
import com.xx.BService;
import junit.framework.TestCase;
import org.junit.Before;
import org.junit.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.Mockito;
import org.mockito.MockitoAnnotations;
public class MockitoTest extends TestCase {
@InjectMocks
private AService aService;
@Mock
private BService bService;
@Before
// 该方法名必须是 setUp，否则不执行，坑死
public void setUp() {
// 启动Mockito,让junit能够识别 @InjectMocks @Mock @Spy等注解
MockitoAnnotations.initMocks(this);
}
@Test
public void testMockito() {
System.out.println(bService);
// 准备数据
// 意思是在调用 bService 的btest方法的时候返回 “b”
Mockito.when(bService.btest()).thenReturn("b");
// 方法调用
String str = aService.test();
// 断言
assertEquals(str, "b");
}
}
代码结构
测试结果
gitee: https://gitee.com/aqu415/demo/tree/master/mockito
相关原理
激活Mockito两种方式
- 在 @brfore 里使用以下代码激活
@Before
// 该方法名必须是 setUp，否则不执行，坑死
public void setUp() {
// 启动Mockito,让junit能够识别 @InjectMocks @Mock @Spy等注解
MockitoAnnotations.initMocks(this);
}
- 在测试类上使用注解激活
例：
@RunWith(MockitoJUnitRunner.class)
public class MockitoTest extends TestCase {
}
激活Mockito是为了让识别 @InjectMocks @Mock @Spy等注解的代码激活
注解说明
- 被 @InjectMocks 注解的类表示一个测试的目标类，会保留方法内部调用的逻辑；内部依赖的属性全部由标记 @Mock 和@Spy的类赋值
- 被 @Mock 注解的类是完全由框架创建，该类会被注入到被@InjectMocks标记的类里；其方法内部逻辑不会被保留，完全由代码Mock
- 被 @Mock 注解的类是完全由框架创建，该类会被注入到被@InjectMocks标记的类里；其方法内部逻辑会被保留
覆盖率
- 方案一：IDEA 自带coverage 功能
覆盖率是单元测试中的一个重要指标，在使用IDEA自带的 coverage 插件执行;
遇到一个坑：提示覆盖率一直是0；
真正原因是测试的覆盖率是按照包来统计的，只要你运行的测试路径下包名(com.xxx)下包含的测试类能够覆盖完对应源码包(com.xxx)下对应的源码，那么覆盖率就是100%；
这里不用管测试路径包下再包含多少子包；
运行指定包下覆盖率测试操作：
- 方案二：jacoco
todo
待完善