该升级你的JUnit版本了-JUnit5基本介绍

作者 | 沈子星

该升级你的JUnit版本了-JUnit5基本介绍_第1张图片

一个立志学会前端的后端工程师。

1. 前言

前段时间看到隔壁架构组写的单元测试表示很是惊艳,发现自己原先写的单元测试有很多不足的地方。于是好好研究了一下 JUnit5 的一些基本功能,分享给大家。

2. JUnit5 介绍

JUnit 作为目前 Java 领域内最为流行的单元测试框架已经走过了数十年。而 JUnit5 在 JUnit4 停止更新版本的3年后终于也于2017年发布了。

作为最新版本的 Junit 框架,JUnit5 与之前版本的 Junit 框架有很大的不同。首先 Junit5 由来自三个不同子项目的几个不同模块组成。

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 的测试引擎。

通过上述的介绍,不知道有没有发现 JUint5 似乎已经不再满足于安安静静做一个单元测试框架了,它的野心很大,想通过接入不同测试引擎,来支持各类测试框架的使用,成为一个单元测试的平台。因此它也采用了分层的架构,分成了平台层,引擎层,框架层。下图可以很清晰的体现出来:

该升级你的JUnit版本了-JUnit5基本介绍_第2张图片

只要实现了JUnit的测试引擎接口,任何测试框架都可以在 JUnit Platform 上运行,这代表着JUnit5将会有着很强的拓展性。

3. 开启一个JUnit5项目吧!

引入JUnit5相比之前的测试框架要相对复杂,需要引入3个模块的 jar 包。由于目前项目都是由 gradle 构建的,因此以下的配置皆为 gradle 配置。

    testCompile("org.junit.platform:junit-platform-launcher:1.6.0")
    testCompile("org.junit.jupiter:junit-jupiter-engine:5.6.0")
    testCompile("org.junit.vintage:junit-vintage-engine:5.6.0")

当然,你可能觉得引那么多包太复杂了,没关系,最新版本的Junit5已经考虑到这点了。现在只需要引入以下一个包即可 Java testCompile("org.junit.jupiter:junit-jupiter:5.6.0")

哦,对了。别忘了我们的 JUnit5 是运行在 JUnit Platform 上的,所以还需要在 build.gradle 中加上这个。(都是踩过的坑....)

test {
    useJUnitPlatform()
}

引入 JUnit5 后即可开启第一个单元测试了。注意 @Test 注解使用的是 org.junit.jupiter.api.Test 包下的,不要再用成Junit4版本的了。

import org.junit.jupiter.api.Test; //注意这里使用的是 jupiter 的 Test 注解!!


public class TestDemo {

  @Test
  @DisplayName("第一次测试")
  public void firstTest() {
      System.out.println("hello world");
  }

4. 基本注解

JUnit5 的注解与 JUnit4 的注解有所变化,以下列出的注解为部分我觉得常用的注解

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

@ParameterizedTest: 表示方法是参数化测试,下方会有详细介绍

@RepeatedTest: 表示方法可重复执行,下方会有详细介绍

@DisplayName: 为测试类或者测试方法设置展示名称

@BeforeEach: 表示在每个单元测试之前执行

@AfterEach: 表示在每个单元测试之后执行

@BeforeAll: 表示在所有单元测试之前执行

@AfterAll: 表示在所有单元测试之后执行

@Tag: 表示单元测试类别,类似于 JUnit4 中的 @Categories

@Disabled: 表示测试类或测试方法不执行,类似于 JUnit4 中的 @Ignore

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

@ExtendWith: 为测试类或测试方法提供扩展类引用

5. 新的特性

5.1 更强大的断言

JUnit5 使用了新的断言类:org.junit.jupiter.api.Assertions。相比之前的 Assert 断言类多了许多新的功能,并且大量方法支持 Java8 的 Lambda 表达式。

以下为两个与 JUnit4 不太一样的断言方式:

5.1.1 异常断言

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


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

}

5.1.2 超时断言

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

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

5.2 参数化测试

参数化测试是 JUnit5 很重要的一个新特性,也是我认为 JUnit5 最惊艳到我的一个功能。它使得用不同的参数多次运行测试成为了可能,也为我们的单元测试带来许多便利。

5.2.1 基础用法

利用 @ValueSource 等注解,指定入参,我们将可以使用不同的参数进行多次单元测试,而不需要每新增一个参数就新增一个单元测试,省去了很多冗余代码。

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

@NullSource: 表示为参数化测试提供一个 null 的入参

@EnumSource: 表示为参数化测试提供一个枚举入参

@ParameterizedTest
@ValueSource(strings = {"one", "two", "three"})
@DisplayName("参数化测试1")
public void parameterizedTest1(String string) {
    System.out.println(string);
    Assertions.assertTrue(StringUtils.isNotBlank(string));
}

5.2.2 进阶用法

当然如果参数化测试仅仅只能做到指定普通的入参还达不到让我觉得惊艳的地步。让我真正感到他的强大之处的地方在于他可以支持外部的各类入参。如:CSV,YML,JSON 文件甚至方法的返回值也可以作为入参。只需要去实现ArgumentsProvider接口,任何外部文件都可以作为它的入参。

@CsvFileSource:表示读取指定 CSV 文件内容作为参数化测试入参

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

/**
 * csv文件内容:
 * shawn,24
 * uzi,50
 */
@ParameterizedTest
@CsvFileSource(resources = "/test.csv")  //指定csv文件位置
@DisplayName("参数化测试-csv文件")
public void parameterizedTest2(String name, Integer age) {
    System.out.println("name:" + name + ",age:" + age);
    Assertions.assertNotNull(name);
    Assertions.assertNotNull(age);
}

@ParameterizedTest
@MethodSource("method")    //指定方法名
@DisplayName("方法来源参数")
public void testWithExplicitLocalMethodSource(String name) {
    System.out.println(name);
    Assertions.assertNotNull(name);
}

static Stream method() {
    return Stream.of("apple", "banana");
}

5.2.3 为什么要用参数化测试?

介绍完参数化测试,可能会觉得这个功能确实强大但是似乎应用场景并不多呀,毕竟我们写的大部分单元测试都不会去复用。其实不然,从外部文件读取入参有一个很大的好处。没错,就是解耦,使得测试逻辑与测试参数解耦,未来如果测试的参数改变了,我们不需要去修改测试代码,只需要修改对应的文件。让我们的测试逻辑不会被大量构造测试参数的代码干扰,能更专注于写好测试逻辑。

目前我们公司也有封装自己的 @FileSource 注解,用于从外部 Json 或 Yaml 文件中读取入参。单元测试代码的逻辑会非常清晰。相比于之前要自己用代码 mock 许多测试参数,使用这种方式可以让测试代码逻辑更加清晰。

@DisplayName("创建咨询来源:成功创建")
@ParameterizedTest
@FileSource(resources = "testData/consultconfig_app_service.yaml")
public void testSaveConsultSource_SUCCESS(ConsultConfigAppServiceDTO dto) {
    //获取入参
    ConsultSourceSaveDTO saveDTO = dto.getSaveConsultSourceSuccess();
    //调用测试方法
    ConsultSourceBO consultSourceBO = consultConfigAppService.saveConsultSource(saveDTO);
    //验证
    Assertions.assertEquals("testConsultSourceCmd", consultSourceBO.getConsultChannelName());
}

5.3 内嵌单元测试

JUnit5 提供了嵌套单元测试用于更好表示各个单元测试类之间的关系。平时我们写单元测试时一般都是一个类对应一个单元测试类。不过有些互相之间有业务关系的类,他们的单元测试完全是可以写在一起,使用内嵌的方式表示,减少测试类的数量防止类爆炸。

JUnit 5提供了 @Nested 注解,能够以静态内部成员类的形式对测试用例类进行逻辑分组

public class NestedTestDemo { @Test
    @DisplayName("Nested")
    void isInstantiatedWithNew() {
        System.out.println("第一层--内嵌单元测试");
    }

    @Nested
    @DisplayName("Nested2")
    class Nested2 {

        @BeforeEach
        void Nested2_init() {
            System.out.println("Nested2_init");
        }

        @Test
        void Nested2_test() {
            System.out.println("第二层-内嵌单元测试");
        }


        @Nested
        @DisplayName("Nested3")
        class Nested3 {

            @BeforeEach
            void Nested3_init() {
                System.out.println("Nested3_init");
            }

            @Test
            void Nested3_test() {
                System.out.println("第三层-内嵌单元测试");
            }
        }
    }

}

5.4 重复测试

JUnit5 为提供了 @RepeatedTest 注解,允许某个单元测试执行多次。其实现在我也并不是很理解为什么要将一个单元测试运行多遍。目前我个人理解是因为单元测试是需要有可重复执行性的,而多次运行单元测试可以更加保证测试的准确性,防止一些随机性。

@RepeatedTest(10) //表示重复执行10次
@DisplayName("重复测试")
public void testRepeated() {
    Assertions.assertTrue(1 == 1);
}

5.5 动态测试

JUnit5 允许我们动态的创建单元测试,通过 @TestFactory 注解,会在运行时生成单元测试。需要注意的是 @TestFactory 修饰的方法本身并不是单元测试,他只是负责生成单元测试。我们只需要返回 DynamicTest 的迭代器甚至是流即可生成不同的单元测试。

(动态测试的应用场景我感觉比较少,各位如果有想到的话,望补充)

@TestFactory
@DisplayName("动态测试")
Iterator dynamicTests() {
    return Arrays.asList(
            dynamicTest("第一个动态测试", () -> assertTrue(true)),
            dynamicTest("第二个动态测试", () -> assertEquals(4, 2 * 2))
    ).iterator();
}

6. 结语

以上就是对 JUnit5 的基本介绍。单元测试是软件开发中一个非常重要的环节,好的单元测试可以让系统的质量可维护性大大增加。而JUnit5提供了很多新特性方便我们对于单元测试的编写,如果你的项目现在还在用 JUnit4,不妨尝试一下 JUnit5,说不定就能打开一个新世界的大门呢?

7. 参考资料

JUnit 5 User Guide

Junit5 新特性你用过多少?

全文完


以下文章您可能也会感兴趣:

  • 锁优化的简单思路

  • iOS开发:Archive、ipa 和 App 包瘦身

  • 压力测试必知必会

  • 分布式 Session 之 Spring Session 架构与设计

  • 缓存的那些事

  • Java 并发编程 -- 线程池源码实战

  • Lombok Builder 构建器做了哪些事情?

  • WePY 2.0 新特性

  • SSL证书的自动化管理

  • 你真的懂 Builder 设计模式吗?论如何实现真正安全的 Builder 模式

我们正在招聘 Java 工程师,欢迎有兴趣的同学投递简历到 [email protected]

你可能感兴趣的:(该升级你的JUnit版本了-JUnit5基本介绍)