Springboot测试篇 | Junit5

---

PS:文章将持续更新修订

---

一. 前言&介绍

简单介绍吧本篇文章将从Junit5到一些Springboot的特殊场景测试配置。
JUnit5简单介绍：Spring Boot2.2.0版本开始引入JUnit5作为单元测试默认库，作为最新版本的JUnit框架，JUnit5与之前版本的Junit框架有很大的不同，由三个不同子项目的几个不同模块组成。
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

• JUnit Platform：Junit Platform是在JVM上启动测试框架的基础，不仅支持Junit自制的测试引擎，其他测试引擎也都可以接入。
• JUnit Jupiter：JUnit Jupiter提供了JUnit5的新的编程模型，是JUnit5新特性的核心，内部包含了一个测试引擎，用于在Junit Platform上运行。
• JUnit Vintage：由于JUint已经发展多年，为了照顾老的项目，JUnit Vintage提供了兼容JUnit4.x,Junit3.x的测试引擎。

值得注意的是：SpringBoot 2.4 以上版本移除了默认对 Vintage 的依赖，如果需要兼容junit4需要自行引入（不能使用junit4的功能 @Test）：

<dependency>
    <groupId>org.junit.vintagegroupId>
    <artifactId>junit-vintage-engineartifactId>
    <scope>testscope>
    <exclusions>
        <exclusion>
            <groupId>org.hamcrestgroupId>
            <artifactId>hamcrest-coreartifactId>
        exclusion>
    exclusions>
dependency>

1. IDEA默认测试目录

默认我们创建好Springboot的项目后都会生成一个默认的配置类

内容如下：

@SpringBootTest
class JunitCsdnApplicationTests {
    @Test
    void contextLoads() {
    }
}

由@SpringBootTest注解进行标注后该类就是Springboot的单元测试类了
提供的依赖也是Springboot帮助我们自动生成的：

<dependency>
     <groupId>org.springframework.bootgroupId>
     <artifactId>spring-boot-starter-testartifactId>
     <scope>testscope>
dependency>

2. 值得一提的小bug

在我们使用springboot项目进行测试时，假如我们是前端项目，并没有导入数据源操作数据库启动单元测试方法时可能会遇到下面这个错误：
springBoot Error creating bean with name 'dataSource' defined in class path resource
原因是：spring boot会默认加载org.springframework.boot.autoconfigure.jdbc.DataSourceAuto Configuration类，DataSourceAutoConfiguration又使用了@Configuration注解向spring注入了dataSource bean，但是因为工程中没有关于dataSource相关的配置信息，当spring创建dataSource bean因缺少相关的信息就会报错。
解决方法：启动工程时排除：DataSourceAutoConfiguration即可，如在@SpringBootApplication启动注解上加 exclude={DataSourceAutoConfiguration.class}

3. IDEA测试技巧

在IDEA的面板的右侧有一个Maven的图标：

点击展开后选择我们的项目点击【生命周期】按住ctrl键我们可以指定运行的生命周期：

像上面这样运行完clean周期后执行test周期会将我们编写的测试用例全部执行一遍

二. Junit5单元测试

1. 常用注解

下面将以一些常用注解为切入点简单介绍Junit5的基本使用，更多注解的使用方法可以自行搜索相关资料或者查询官网。

1. @Test

表示方法是测试方法。但是与JUnit4的@Test不同，他的职责非常单一不能声明任何属性，拓展的测试将会由Jupiter提供额外测试：

2. @Autowired

将Spring中的容器注入到环境中，方便在单元测试中使用Spring中的容器。

3. @Transactional

标注@Transactional注解主要是为了防止数据污染，如果单元测试方法中有对数据库进行操作，执行完测试方法后自动进行数据回滚防止对数据的污染，但是这个注解在开发中慎用，会几种情况下该注解会失效，这个感觉兴趣的朋友可以去搜索一下相关文章。

但是使用这个注解需要引入Spring boot提供的JDBC或JPA依赖：

<dependency>
   <groupId>org.springframework.bootgroupId>
   <artifactId>spring-boot-starter-jdbcartifactId>
   <scope>testscope>
dependency>
 
<dependency>
   <groupId>org.springframework.bootgroupId>
   <artifactId>spring-boot-starter-data-jpaartifactId>
   <scope>testscope>
dependency>

4. @DisplayName

为测试方法起名，既可以在方法上进行标注也可以在类上面进行标注:

@SpringBootTest
@DisplayName("测试类")
class JunitCsdnApplicationTests {

    @DisplayName("功能测试")
    @Test
    void contextLoads() {
        System.out.println("靓仔,又来学JAVA了?");
    }

}

运行效果：

5. @BeforeEach

该注解标注的方法，在每个单元测试之前都会执行一次，通常用来加载其他单元测试所用资源。

6. @AfterEach

该注解标注的方法，在每个单元测试执行之后都会自动执行一次，通常用来释放其他单元测试造成的内存

7. @BeforeAll

表示在所有单元测试之前执行 ，通常只有在一次性启动整个类的时候才会执行这个注解标注的方法。

值得注意的是该注解标注的方法必须是一个静态方法，也就是必须是用static标注的方法

8. @AfterAll

表示在所有单元测试之后执行，通常只有在一次性启动整个类的时候才会执行这个注解标注的方法。

值得注意的是该注解标注的方法必须是一个静态方法，也就是必须是用static标注的方法

9. @Tag

表示单元测试类别，类似于JUnit4中的@Categories

10. @Disabled

表示测试类或测试方法不执行，类似于JUnit4中的@Ignore，也就是达到一个禁用的效果。

11. @Timeout

表示测试方法运行如果超过了指定时间将会返回错误

12. @RepeatedTest

可以使方法重复测试，我们可以指定方法重复的次数：

上面的意思表示上面的单元测试执行后会循环执行五次

2. 断言

断言(assertions)是测试方法中的核心部分，用来对测试需要满足的条件进行验证。
这些断言方法都是 org.junit.jupiter.api.Assertions 的静态方法，检查业务逻辑返回的数据是否合理。
所有的测试运行结束以后，会有一个详细的测试报告；
JUnit 5 内置的断言可以分成如下几个类别：

1. 简单断言

用来对单个值进行简单的验证，如：

方法	说明
assertEquals	判断两个对象或两个原始类型是否相等
assertNotEquals	判断两个对象或两个原始类型是否不相等
assertSame	判断两个对象引用是否指向同一个对象
assertNotSame	assertNotSame判断两个对象引用是否指向不同的对象
assertTrue	判断给定的布尔值是否为 true
assertFalse	判断给定的布尔值是否为 false
assertNull	判断给定的对象引用是否为 null
assertNotNull	判断给定的对象引用是否不为 null

如果断言失败如下面情况：

Idea会给我们爆出错误信息

值得注意的是： 只要前面的断言失败后面的代码都不会被执行，参数一般都是期望值，参数二是判断值，二参数三一般都是断言错误后的提示信息。

2. 数组断言

通过 assertArrayEquals 方法来判断两个对象或原始类型的数组是否相等

@Test
@DisplayName("array assertion")
public void array() {
 assertArrayEquals(new int[]{1, 2}, new int[] {1, 2});
}

3. 组合断言

assertAll 方法接受多个 org.junit.jupiter.api.Executable 函数式接口的实例作为要验证的断言，可以通过 lambda 表达式很容易的提供这些断言，全部断言成功才算成功，有一个失败都算失败：

@Test
@DisplayName("assert all")
public void all() {
// Math 是组名
 assertAll("Math",
    () -> assertEquals(2, 1 + 1),
    () -> assertTrue(1 > 0)
 );
}

4. 异常断言

在JUnit4时期，想要测试方法的异常情况时，需要用@Rule注解的ExpectedException变量还是比较麻烦的，而JUnit5提供了一种新的断言方式Assertions.assertThrows() ,配合函数式编程就可以进行使用：

@Test
@DisplayName("异常测试")
public void exceptionTest() {
    ArithmeticException exception = Assertions.assertThrows(
           //扔出断言异常
            ArithmeticException.class, () -> System.out.println(1 % 0),"出现数学运算异常");

}

5. 超时异常

Junit5还提供了Assertions.assertTimeout() 为测试方法设置了超时时间：

@Test
@DisplayName("超时测试")
public void timeoutTest() {
    //如果测试方法时间超过1s将会异常
    Assertions.assertTimeout(Duration.ofMillis(1000), () -> Thread.sleep(500));
}

6. 快速失败

通过 fail 方法直接使得测试失败：

@Test
@DisplayName("fail")
public void shouldFail() {
 fail("This should fail");
}

3. 前置条件

JUnit 5 中的前置条件（assumptions(假设)）类似于断言，不同之处在于不满足的断言会使得测试方法失败，而不满足的前置条件只会使得测试方法的执行终止。前置条件可以看成是测试方法执行的前提，当该前提不满足时，就没有继续执行的必要。

@DisplayName("前置条件")
public class AssumptionsTest {
 private final String environment = "DEV";
 
 @Test
 @DisplayName("simple")
 public void simpleAssume() {
    assumeTrue(Objects.equals(this.environment, "DEV"));
    assumeFalse(() -> Objects.equals(this.environment, "PROD"));
 }
 // simpleAssume方法中如果assumeTrue的结果为True才会继续向下执行，如果结果非预期则会爆出错误
 // 下面的测试逻辑也不会被执行

4. 参数化测试

参数化测试是JUnit5很重要的一个新特性，它使得用不同的参数多次运行测试成为了可能，也为我们的单元测试带来许多便利。
利用@ValueSource等注解，指定入参，我们将可以使用不同的参数进行多次单元测试，而不需要每新增一个参数就新增一个单元测试，省去了很多冗余代码。

1. @ParameterizedTest

使用@ParameterizedTest注解进行标注后表示该测试不是一个不同的单元测试而是一个参数化测试，是Junit5参数化测试的重要注解。

2. @ValueSource

为参数化测试指定入参来源，支持八大基础类以及String类型,Class类型：

@ParameterizedTest
@ValueSource(strings = {"one", "two", "three"}) // 依次传递给下面的形参，执行3次
@DisplayName("参数化测试1")
public void parameterizedTest1(String string) {
    System.out.println(string);
    Assertions.assertTrue(StringUtils.isNotBlank(string));
}

3. @MethodSourc

表示读取指定方法的返回值作为参数化测试入参(注意方法返回需要是一个流)，例如：

static Stream<String> streamtext(){
      return Stream.of("牛","马","人")
    }
    @ParameterizedTest
    @DisplayName("参数化测试1")
    @MethodSource("streamtext")
    public void parameterizedTest(String string) {
        System.out.println(string);
    }

4. 加载测试配置类

学习过Spring的知识，我们都知道，其实一个spring环境中可以设置若干个配置文件或配置类，若干个配置信息可以同时生效。现在我们的需求就是在测试环境中再添加一个配置类，然后启动测试环境时，生效此配置就行了。其实做法和spring环境中加载多个配置信息的方式完全一样。具体操作步骤如下：
步骤①：在测试包test中创建专用的测试环境配置类：

@Configuration
public class MsgConfig {
    @Bean
    public String msg(){
        return "bean msg";
    }
}

上述配置仅用于演示当前实验效果，实际开发可不能这么注入String类型的数据

步骤②：在启动测试环境时，导入测试环境专用的配置类，使用@Import注解即可实现

@SpringBootTest
@Import({MsgConfig.class})
public class ConfigurationTest {

    @Autowired
    private String msg;

    @Test
    void testConfiguration(){
        System.out.println(msg);
    }
}

到这里就通过@Import属性实现了基于开发环境的配置基础上，对配置进行测试环境的追加操作，实现了1+1的配置环境效果。这样我们就可以实现每一个不同的测试用例加载不同的bean的效果，丰富测试用例的编写，同时不影响开发环境的配置。

5. 随机值

对于测试用例的数据固定书写肯定是不合理的，springboot提供了在配置中使用随机值的机制，确保每次运行程序加载的数据都是随机的，具体如下：

testcase:
  book:
    id: ${random.int}
    id2: ${random.int(10)}
    type: ${random.int!5,10!}
    name: ${random.value}
    uuid: ${random.uuid}
    publishTime: ${random.long}

当前配置就可以在每次运行程序时创建一组随机数据，避免每次运行时数据都是固定值的尴尬现象发生，有助于测试功能的进行。数据的加载按照之前加载数据的形式，使用@ConfigurationProperties注解即可：

@Component
@Data
@ConfigurationProperties(prefix = "testcase.book")
public class BookCase {
    private int id;
    private int id2;
    private int type;
    private String name;
    private String uuid;
    private long publishTime;
}

5. Web环境测试

1. 环境搭建

测试类中启动web环境：每一个springboot的测试类上方都会标准@SpringBootTest注解，而注解带有一个属性，叫做webEnvironment。通过该属性就可以设置在测试用例中启动web环境，具体如下：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class WebTest {	
}

测试类中启动web环境时，可以指定启动的Web环境对应的端口，springboot提供了4种设置值，分别如下：

• MOCK：根据当前设置确认是否启动web环境，例如使用了Servlet的API就启动web环境，属于适配性的配置
• DEFINED_PORT：使用自定义的端口作为web服务器端口
• RANDOM_PORT：使用随机端口作为web服务器端口
• NONE：不启动web环境

通过上述配置，现在启动测试程序时就可以正常启用web环境了，建议大家测试时使用RANDOM_PORT，避免代码中因为写死设定引发线上功能打包测试时由于端口冲突导致意外现象的出现。就是说你程序中写了用8080端口，结果线上环境8080端口被占用了，结果你代码中所有写的东西都要改，这就是写死代码的代价。现在你用随机端口就可以测试出来你有没有这种问题的隐患了。
测试环境中的web环境已经搭建好了，下面就可以来解决第二个问题了，如何在程序代码中发送web请求。
测试类中发送请求：对于测试类中发送请求，其实java的API就提供对应的功能，只不过平时各位小伙伴接触的比较少，所以较为陌生。springboot为了便于开发者进行对应的功能开发，对其又进行了包装，简化了开发步骤，具体操作如下：
步骤①：在测试类中开启web虚拟调用功能，通过注解@AutoConfigureMockMvc实现此功能的开启：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
//开启虚拟MVC调用
@AutoConfigureMockMvc
public class WebTest {
}

步骤②：定义发起虚拟调用的对象MockMVC，通过自动装配的形式初始化对象：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
//开启虚拟MVC调用
@AutoConfigureMockMvc
public class WebTest {

    @Test
    void testWeb(@Autowired MockMvc mvc) {
    }
}

步骤③：创建一个虚拟请求对象，封装请求的路径，并使用MockMVC对象发送对应请求：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
//开启虚拟MVC调用
@AutoConfigureMockMvc
public class WebTest {

    @Test
    void testWeb(@Autowired MockMvc mvc) throws Exception {
        //http://localhost:8080/books
        //创建虚拟请求，当前访问/books
        MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
        //执行对应的请求
        mvc.perform(builder);
    }
}

执行测试程序，现在就可以正常的发送/books对应的请求了，注意访问路径不要写http://localhost:8080/books，因为前面的服务器IP地址和端口使用的是当前虚拟的web环境，无需指定，仅指定请求的具体路径即可。

2. web环境请求结果比对

上一节已经在测试用例中成功的模拟出了web环境，并成功的发送了web请求，本节就来解决发送请求后如何比对发送结果的问题。其实发完请求得到的信息只有一种，就是响应对象。至于响应对象中包含什么，就可以比对什么。常见的比对内容如下：

• 响应状态匹配

  @Test
  void testStatus(@Autowired MockMvc mvc) throws Exception {
      MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
      ResultActions action = mvc.perform(builder);
      //设定预期值 与真实值进行比较，成功测试通过，失败测试失败
      //定义本次调用的预期值
      StatusResultMatchers status = MockMvcResultMatchers.status();
      //预计本次调用时成功的：状态200
      ResultMatcher ok = status.isOk();
      //添加预计值到本次调用过程中进行匹配
      action.andExpect(ok);
  }
  

• 响应体匹配（非json数据格式）

  @Test
  void testBody(@Autowired MockMvc mvc) throws Exception {
      MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
      ResultActions action = mvc.perform(builder);
      //设定预期值 与真实值进行比较，成功测试通过，失败测试失败
      //定义本次调用的预期值
      ContentResultMatchers content = MockMvcResultMatchers.content();
      ResultMatcher result = content.string("springboot2");
      //添加预计值到本次调用过程中进行匹配
      action.andExpect(result);
  }
  

• 响应体匹配（json数据格式，开发中的主流使用方式）

  @Test
  void testJson(@Autowired MockMvc mvc) throws Exception {
      MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
      ResultActions action = mvc.perform(builder);
      //设定预期值 与真实值进行比较，成功测试通过，失败测试失败
      //定义本次调用的预期值
      ContentResultMatchers content = MockMvcResultMatchers.content();
      ResultMatcher result = content.json("{\"id\":1,\"name\":\"springboot2\",\"type\":\"springboot\"}");
      //添加预计值到本次调用过程中进行匹配
      action.andExpect(result);
  }
  

• 响应头信息匹配

  @Test
  void testContentType(@Autowired MockMvc mvc) throws Exception {
      MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
      ResultActions action = mvc.perform(builder);
      //设定预期值 与真实值进行比较，成功测试通过，失败测试失败
      //定义本次调用的预期值
      HeaderResultMatchers header = MockMvcResultMatchers.header();
      ResultMatcher contentType = header.string("Content-Type", "application/json");
      //添加预计值到本次调用过程中进行匹配
      action.andExpect(contentType);
  }
  

​ 基本上齐了，头信息，正文信息，状态信息都有了，就可以组合出一个完美的响应结果比对结果了。以下范例就是三种信息同时进行匹配校验，也是一个完整的信息匹配过程。

@Test
void testGetById(@Autowired MockMvc mvc) throws Exception {
    MockHttpServletRequestBuilder builder = MockMvcRequestBuilders.get("/books");
    ResultActions action = mvc.perform(builder);

    StatusResultMatchers status = MockMvcResultMatchers.status();
    ResultMatcher ok = status.isOk();
    action.andExpect(ok);

    HeaderResultMatchers header = MockMvcResultMatchers.header();
    ResultMatcher contentType = header.string("Content-Type", "application/json");
    action.andExpect(contentType);

    ContentResultMatchers content = MockMvcResultMatchers.content();
    ResultMatcher result = content.json("{\"id\":1,\"name\":\"springboot\",\"type\":\"springboot\"}");
    action.andExpect(result);
}