Junit5的朋友圈，了解一下?

着急的同学可以直接拉到底看总结。

在某次关于自主可控的技术交流中，当讨论了国产CPU和操作系统的发展近况时，来自某个国内主要的国产CPU设计单位的专家讲到，他们设计的国产CPU目前已经在超级计算机上得到了较大规模的应用，并且已经能够兼容诸多的Linux操作系统。

但是对于发展“通用型”CPU的目标来说，最主要的瓶颈还是在于“生态圈”的建设。从最基础的C/C 编译器，到JAVA虚拟机、数据库等配套基础软件的支持的匮乏，极大地限制了国产CPU在各个金融等各个领域的业务拓展。

为此，他们也开始组建所谓的自主可控联盟，联合了操作系统、数据库等厂商，为行业客户提供一张套的自主可控替代方案。

这个故事让笔者想起了一则广告词，“大家好，才是真的好”。做一个项目，实现一个目标，往往不是个人或者自己做好了就够了，需要前后左右各个方面的协同。中间有一环掉链子了，或者支持力度不够了，可能就会影响整个事情的交付结果。 对于自动化测试来说，Junit5的推出已经有好几年了。那么目前整个测试生态圈对Junit5的支持如何呢？有什么在制约或者妨碍用户从Junit4升级甚至从别的自动化测试框架迁移到Junit5呢？ 由此，笔者将在本文中Junit5推出之后，整个测试生态圈的支持情况做一个盘点。 首先，Junit5 不再是一个单一的jar包，而是由三部分组成。 JUnit 5 = JUnit Platform JUnit Jupiter JUnit Vintage 其中 JUnit平台，其主要作用是在JVM上启动测试框架。它定义了一个抽象的TestEngineAPI来定义运行在平台上的测试框架，同时还支持通过命令行、Gradle和Maven来运行平台。 JUnit Jupiter，包含了JUnit5最新的编程模型和扩展机制。 JUnit Vintage，允许在平台上运行JUnit3和JUnit4的测试用例。 JUnit5对Java运行环境的最低要求是Java8,同时也兼容测试旧版本JDK编译出来的代码。

构建工具的支持

我们首先来看下构建工具的支持情况。

Maven - 姗姗来迟的官方支持

JUnit5在2017年9月10日（教师节）正式发布了其5.0.0GA版本。

通过这篇文章,我们可以了解到，直到2018年10月24日Maven 3.6.0发布，Maven才正式原生支持Junit5。在这个版本中，Maven团队一并发布了 Maven Surefire Plugin 2.22.0 和Maven Failsafe plugin 2.22.0，进而解决了对Junit5的支持问题。 在此之前，为了能在Maven中运行Junit5的测试用例，需要为 Maven Surefire plugin额外提供一个Junit5团队提供的Junit Provider。

代码语言：javascript复制

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.19.1</version>
    <dependencies>
        <dependency>
            <groupId>org.junit.platform</groupId>
            <artifactId>junit-platform-surefire-provider</artifactId>
            <version>1.1.0</version>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
            <version>5.1.0</version>
        </dependency>
    </dependencies>
</plugin>

如果将Maven升级到3.6.0及以上版本，那么unit-jupiter-engine这个依赖就不需要了。而这中间差了有快一年的时间。考虑到其实早在2016年Junit5就已经发布了5.0 M1这样一个可用版本，并提供了上述workaround,Maven对于Junit5的支持其实要落后了整整2年。

当然这样的支持也不是一番风顺的。在Junit5的缺陷清单上，出现过1579号缺陷，并被认为是maven-surefire#193所导致的。

Gradle-类似的故事

翻看了Gradle的发布历史后，发现Gradle团队在4.6版本的Release Notes中兴奋地宣布了对Junit5的支持。

这个时间，大概比Maven团队早了有半年，支持力度略微好一点。从Gradle团队热情洋溢的介绍和致谢词中我们也能感受到，为了能让Gradle尽早原生支持Junit5, 后者的团队应该是付出了很多的努力的。

IDE 编码工具的支持--巴铁一般的友谊

再来看一下IDE的支持情况。相对于构建工具来说，IDE的支持要更为提前一些，甚至都做到了同步发布。

IntelliJ IDEA

IntelliJ IDEA 在其2016.2 版本中提供了对Junit 5的支持，时间是在2006年的7月份，几乎是和Junit5 M1版本同一时间。当然作为第一个版本，也是有不少问题的。因此紧跟着Junit5 GA 的发布，在2017年11其2017.3版本中专门进行了优化，还提供了Junit4向Junit5用例的一键迁移功能。

Eclipse

Eclipse 在 Oxygen.1a (4.7.1a), 也几乎是在Junit5 GA 的同时进行发布,在其官方的发布说明中，Junit5甚至还排在对Java9支持的前面。

<iframe width="560" height="315" src="https://www.youtube.com/embed/wI3VC1lhbK8" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

其余好友

Spring

对于Spring家族来说，之前是通过@RunWith的注解来执行Junit用例的。在Junit5中，不再支持@RunWith的注解了，因此为了能将用例迁移到Junit5，Spring团队利用了@ExtendWith的注解。 迁移前的用例是这样的：

代码语言：javascript复制

@RunWith(SpringJUnit4ClassRunner.class)
public class GreetingsSpringTest {
    // ...
}

迁移到Junit5的用例是这样的

代码语言：javascript复制

@ExtendWith(SpringExtension.class)
public class GreetingsSpringTest {
    // ...
}

其中的SpringExtension类是由Spring5中的 Spring TestContext Framework所提供的。具体的需求可以参见 https://jira.spring.io/browse/SPR-13575。而Spring5 GA的时间则在2017年9月28日，在Junit5 GA的同月，也基本上是同步了。

SpringBoot

在SpringBoot中，这一切就更简单了。

代码语言：javascript复制

@SpringBootTest
public class GreetingsSpringBootTest {
    // ...
}

还是原来的味道，只是需要在pom.xml中修改下配方。

代码语言：javascript复制

        <!-- exclude junit 4 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>junit</groupId>
                    <artifactId>junit</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <!-- junit 5 -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
            <version>${junit-jupiter.version}</version>
            <scope>test</scope>
        </dependency>

这里有一个事实是，时至今日spring-boot-starter-test的默认Junit框架版本还是Junit4。

Mockito

再来看一下Mock工具对Junit5的支持情况。以Mockito为例，在Junit5推出的初期，Junit团队甚至利用JUnitExtension机制，同样地为Mockito提供了扩展的样例，可以让Junit5用户拥有基本的Mockito功能。 https://github.com/junit-team/junit5-samples/blob/r5.0.0/junit5-mockito-extension/src/main/java/com/example/mockito/MockitoExtension.java 与此同时，就在Mockito2发布的前夕（和Junit5 M1差不多前后），收到了关于对JUnit5支持的需求。 Introduce MockitoExtension for JUnit Jupiter (a.k.a. JUnit 5) #445 https://github.com/mockito/mockito/issues/445 根据Github上各方的留言来看，这个需求直到2018年3月份才在Mockito 3.0和2.x发布。随着Junit5自身的GA和特性的增加，Mockito团队也在不断地为MockitoExtension增加新的功能。

简单总结下

我们以2个IDE、2个构建工具以及1个Mock工具为例，通过回顾这5个和Junit这个测试框架最为密切的工具支持Junit5的心路历程，我们可以总结出以下几点 1）GA不意味着成功，只是开始，只是开始。 2）提早发布M版本（预览版）供上下游配套开发，争取时间，能同步发布。 3）在配套方尚未就绪之前，最好能提供临时解决方案，如JUnit团队为Maven/Gradle提供了插件，为Mockito则提供了扩展的样例。 4）最直接的办法，是出人出代码，帮助配套方尽快完成开发测试。 （参见Gradle团队那封热情洋溢的release notes)

maven gradle android spring ide

0 人点赞