最新版本的JUnit在2017年的第三季度已经发布了final release版本。大量的里程碑改进加入了新版本中。我希望你能够尽快的使用起来，这篇文章的主题，我列出了7个点，鼓励大家立刻开始去玩玩JUnit5.
立刻可用
当一门语言、一款应用服务器或代码库的新版本出现的时候，大部分开发人员往往会等到业界真正开始推行这个产品的时候，才开始选择学习。这种情况经常出现，看看JavaScript，在ES2015规范发布两年后，大部分主流Web浏览器仍在努力支持所有语言特征。虽然JS转化器在一定程度上推动了标准的实施，但是确实是饶了一个弯路。
JUnit5团队从一开始就考虑了新版本的这些问题。IntelliJ IDEA已经支持IDE中运行JUnit5测试，Eclipse也将支持JUnit5列入了其beta support列表中。两款最流行的构建工具，Maven和Gradle，已经支持JUnit5测试。如果你不熟悉这些流行的工具，JUnit5也提供了一款控制台工具帮你自动的运行JUnit5测试。就算这些都不成立，还有一个JUnit4的测试运行工具能够在JUnit4环境中测试新版本的测试代码。你看看，所有的配套都准备好了。
易于学习
第一眼看上去，新的API（新命名为JUnit Jupiter）和他的前身非常像。这个相似程度之高，甚至你会觉得这个新的版本就是新瓶装旧酒。包括最流行的那些断言方法也是一样的。唯一的区别就是放在了不同的包中，并且参数的顺序有了一些区别。一些JUnit4中的著名的注解修改了名字，但是作用都是差不多的。如果你对JUnit4比较熟悉，那么你要掌握JUnit5的基础使用，只需要几分钟。
这个时候，你可能会想，既然两个版本这么像，那为啥我还要升级呢？简单来说，JUnit5更像是JUnit4的一个超集，他提供了非常多的增强。
全新的功能
一旦你熟悉了JUnit5的基础内容，你可以顺利进入下一个阶段，根据你的需求，你可能会考虑以下几个进阶点：
新的断言
嵌套测试类 - 不仅仅是BDD（Behavior Driven Development）开发人员大力推崇
动态测试 - 在运行时生成测试用例
扩展测试 - 允许你重新定义测试的行为，允许你使用插件的形式重用你的测试类。
解决了前序版本的问题
没有完美的东西，JUnit4也一样。在JUnit4中，在社区中对几个大大小小的问题都有各种讨论和改进，我们来看看这些问题。
异常验证
异常检查可以说是JUnit4中一个标志性的问题。我们来考虑一下下面这个JUnit4测试：
@Test(expected = IllegalArgumentException.class)
public void shouldThrowException() throws Exception {
Task task = buildTask();
LocalDateTime oneHourAgo = LocalDateTime.now().minusHours(1);
task.execute(oneHourAgo);
}
想象我们运行这个测试，如果传入到execute()方法中的参数是一个过去的时间，会正常抛出一个IllegalArgumentException异常。这种情况下，测试会运行的正确。但是如果在buildTask()方法中抛出一个异常呢？测试会正常执行，并且会提示你得到的异常和期望异常不匹配。这里，问题就出来了，我们只是希望测试在指定位置得到指定的异常，而不是在整个测试体中出现的异常，都作为对比异常。在JUnit5中，提供了一个assertThrows()方法，可以非常轻松的处理这个问题：
@Test
void shouldThrowException() throws Exception {
Task task = buildTask();
LocalDateTime oneHourAgo = LocalDateTime.now().minusHours(1);
assertThrows(IllegalArgumentException.class,
() -> task.execute(oneHourAgo));
}
超时时间测试
额外的，添加了一组新的断言，用于在lambda样式断言中衡量代码超时时间，在这种情况下，就不会担心测试的setup阶段对代码执行时间的影响，你可以指定只去衡量某一段代码的执行时间。另外，还提供了一个选项，当已经出现超时的时候，你是选择停止应用执行或者是继续当前测试以衡量代码执行的真实完整时间。
@Test
void shouldTimeout() throws Exception {
ExpensiveService service = setupService();
assertTimeout(ofSeconds(3), () -> {
service.expensiveMethod();
});
}
参数化测试
在JUnit4中，如果想要实现参数化测试（使用不同的参数来测试相同的一个方法），只能使用测试类中的字段来实现，在JUnit5中，提供了参数化测试来实现这个需求。不同的参数值可以直接和一个测试方法关联，并且允许直接在一个测试类中提供不同的参数值直接参与测试，这些在JUnit4中，都是不可能实现的。
测试的参数可以通过一组CSV格式的字符串，外部的CSV文件，枚举，工厂方法，或者指定的提供类来提供。CSV中的字符串类型的值可以自动的转化为指定的类型，并且你可以完成自己的类型转换器，将String转成你希望的任何指定类型。
多运行器
JUnit4中最让人诟病的可能就是不能使用多个测试运行器测试。参数化测试或者嵌套测试的问题，可以通过测试运行器来解决，但问题是我们只能使用一个测试运行器。比如，在Spring4.2之前，每一个依赖于Spring上下文的测试都只能使用SpringJUnit4ClassRunner，在4.2之后，你可以使用专用的规则来（SpringClassRule）处理这个问题，允许你使用不同的测试运行器来运行测试，但是同一时间，仍然只能使用一次。JUnit4从一开始因为兼容问题，就根本没有设计运行器扩展的问题。JUnit 5团队选择了一条不同的路径，并计划了新版本的架构来解决这个问题。
迁移简单
到这里，你是否又担心在目前的项目中已经有上百个测试用例，为了获得JUnit5的好处，而不得不重写这些测试代码？请放松，JUnit5团队提供了多种升级的选择。第一点，你可以在一个项目中同时使用JUnit4和JUnit5，而不用担心出现冲突。当你添加新的JUnit依赖到项目中，有两种方式可以同时运行测试。
侵略性最小的方式是使用JUnit5 API完成新的测试，并且使用专用的JUnitPlatform运行器在JUnit4下运行。但是，刚才我们不是才说JUnit4的症结是运行器么？当然，这个JUnitPlatform是一个受限的运行器，他只能支持新版本的一部分功能。但是，这仍然是一个开始使用新版本API的不错的开始。最快的学习方法就是在真实项目中使用，对吧。
第二种方式，是将JUnit5作为主要的测试运行器。除了能获取框架带来的诸多优势，你也可以在新的平台中运行老版本的测试，当然有一些限制。由于设计概念上的区别，JUnit4中只有部分的一些特性能够在JUnit5中运行。在你迈进JUnit5之前，先了解一下这些限制：http://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4-rulesupport
做贡献的机会
因为新版本还在持续开发过程中，这个时候提交一些有用的想法，是非常好的机会。框架的使用者，你期望在项目中能用到哪些新的功能，每一个有用的想法都可以通过issue提交到JUnit5项目中。
但是，当你提交一个新的issue的时候，请确保这个想法在框架中确实没有实现。尽量不要为团队开发者去处理已经存在的issue或者没有太多价值的issue。但是，如果你有一个好的建议，不要犹豫，请提交一个issue。对开源的贡献一定不是仅仅只局限于代码提交，贡献idea同样重要。JUnit5的issues列表：https://github.com/junit-team/junit5/issues
JVM测试
JUnit5的目标，不仅仅只是瞄准测试框架。JUnit5的重大改进不仅仅只是打破了常规的API，或者引入了新的扩展模型。一个非常重要的目标，是打造一个基于JVM测试框架的基础平台。这意味着什么？我们来看一个图：
你可以看到，就像洋葱一样，JUnit5的架构也是分层的。最核心的就是基础平台。IDE和构建工具都是作为客户端和这个核心平台交互，以达到在项目中运行测试的目的。TestEngine的实现在平台中用于发现和运行测试，并且输出测试报告，并通过核心平台返回给客户端。
核心关注点是扩展能力，但并不仅仅只是存在于测试类级别。在整个测试平台级别，都提供了足够的扩展能力。任何一个框架都可以在JUnit平台上运行他自己的测试，只需要提供框架本身对TestEngine接口的实现即可。只需要一点点工作，通过这一个扩展点，框架就能得到所有IDE和构建工具在测试上的支持。这对于新框架来说绝对是好事，在测试和构建这块的门槛更低。
这些对于一个开发者来说意味着什么呢？这意味着一个测试框架和JVM开发市场上所有主流的工具集成的时候，你能更容易的说服你的经理，开发leader，或者不管是谁阻碍你引入这个测试框架的人。 JUnit Vintage就是一个TestEngine实现，用于执行JUnit4的测试。