junit5和junit4_JUnit 5 –下一代JUnit的初步了解

junit5和junit4

2月初， JUnit 5（又名JUnit Lambda）团队发布了一个alpha版本。由于JUnit 4是我工具箱中使用最多的项目之一，因此我认为值得一看下一个主要版本。

我试用了最新版本，并记下了我在这里发现值得注意的更改。

安装JUnit 5

不用说，一个名为JUnit Lambda的项目需要Java 1.8或更高版本。如果给出了，那么包括库就很简单了。可从Sonatype的快照存储库（ https://oss.sonatype.org/content/repositories/snapshots/org/junit/ ）获得当前alpha发行渠道的最新版本。

可以使用Maven和Gradle消耗工件。如果您希望手动维护依赖关系，那么还有一个可用的zip发行版，其中包含编译和运行JUnit 5的所有内容。

在开发时，仅依赖org.junit:junit5-api模块就足够了。

请注意，在指定快照存储库时，应将其配置为从不缓存工件，以便始终使用最新版本。

从JUnit 4减少松动

据我所知，新版本是对库的完全重写，对旧版本没有任何依赖性。因此，您可以享受传统的免费测试（至少一段时间；-）。

但是，当然有一条迁移路径可以使两个版本共存，并使您能够在使用JUnit 5编写新测试时维护现有测试代码库。

相同但不同

但是，让我们最后来看一下JUnit 5测试的样子。乍一看，变化不大。一个简单的测试课程…

class FirstTests {@Testvoid firstTest() {fail();}
}

…与JUnit 4测试几乎没有区别。

但是，您发现细微的差别了吗？是的，测试不再需要公开，但是如果您愿意，测试当然也可以。

尽管注释仍用于标识设置和拆除测试环境的方法，但其名称已更改。 @BeforeClass/AfterClass现在是@BeforeAll/AfterAll而@Before/After现在是@BeforeEach/AfterEach 。

使用@Disabled批注仍然可以忽略测试。

@Test与@Test

如您所见，测试仍然使用@Test注释标记。但是要小心，如果您碰巧在类路径上也有JUnit 4。 JUnit 5 @Test自己的@Test批注，因此请确保导入正确的org.junit.gen5.api.Test 。否则，JUnit 5测试运行程序将找不到您的测试。

要注意的另一件事是新的@Test注释不提供其他服务。如果你曾经使用timeout或expected不时，你将需要更换他们的JUnit 5。

使用JUnit 5运行测试

难怪还没有IDE支持可以运行JUnit 5测试。因此，我使用ConsoleRunner来执行实验。以这种方式运行测试还需要三个模块：

org.junit:junit5-engine
org.junit:junit-launcher
org.junit:junit-console

我选择的IDE是Eclipse，为了从那里使用ConsoleRunner运行测试，我不得不手动扩展启动配置的Classpath 。仅在添加包含已编译测试的test-classes输出文件夹之后，它们才会被拾取。但是，这个怪异也可能是由于我对Maven的了解不足，或者是由于Eclipse Maven集成中的特殊性。

JUnit 5团队还提供了基本的插件来执行Maven和Gradle构建中的测试。如果您想尝试一下，请参阅“ 构建支持”一章。

断言

乍一看，断言并没有太大变化，只是断言现在位于org.junit.gen5.api.Assertions类中。

但是仔细观察发现， assertThat()消失了，不幸的是依赖于Hamcrest。这些方法实际上复制了MatcherAssert提供的API， MatcherAssert JUnit的MatcherAssert版本绑定到Hamcrest库。这种依赖性有时会导致类解析冲突。特别是与其他库一起使用时，更糟的是，它们会自己包含Hamcrest的副本。

另一个更改是新的assertAll()方法，该方法用于对断言进行分组。例如

assertAll( "names", () -> {assertEquals( "John", person.getFirstName() );assertEquals( "Doe", person.getLastName() );
} );

将报告一个MultipleFailuresError其中包含组中所有失败的断言。

然后，测试执行者有责任以适当的方式显示此故障。但是，当前的ConsoleRunner实现尚未考虑分组故障，仅报告第一个故障：

Finished:    testNames [junit5:com...GroupAssertionsTest#testNames()]=> Exception: names (1 failure)expected: <John> but was: <Mary>

我的第一个未经过滤的想法是，如果需要对断言进行分组，则可能是将代码分成多个测试的标志。但是我还没有真正使用分组断言，并且可能还有一些地方完全有意义。

测试异常

测试异常已经统一。要更换expected和ExpectedException现在有一个expectThrows断言评估lambda表达式，并验证它抛出指定类型的异常。

例如，

@Test
void testException() {Foo foo = new Foo();Throwable exception = expectThrows( IllegalStateException.class, foo::bar );assertEquals( "some message", exception.getMessage() );
}

…如果调用foo::bar()没有抛出IllegalStateException将失败。否则，将返回抛出的异常，并且可以对其进行进一步验证。如果引发的异常assertThrows() ，则还有一个assertThrows()方法返回void。

再见亚军，规则和ClassRule

JUnit 5不再知道运行器，规则或类规则。这些部分竞争的概念已由单个一致的扩展模型代替。

通过使用@ExtendWith注释测试类或测试方法，可以声明性地使用扩展。例如，希望使用模拟实例初始化某些字段的测试可以使用Mockito扩展，如下所示：

@ExtendWith(MockitoExtension.class)
class MockedTest {@MockPerson person;// ...}

如果您对此主题有更多兴趣，请继续关注有关扩展以及如何将现有规则迁移到我计划编写的自定义扩展的单独文章。

测试方法参数

在JUnit 5中，现在允许方法具有参数。这允许在方法级别注入依赖项。

为了提供参数，所谓的解析器是必需的，它是实现MethodParameterResolver的扩展。与所有其他扩展一样，要将解析器用于给定的方法或类，则需要使用@ExtendWith进行声明。还有两个不需要明确声明的内置解析器。它们提供类型TestInfo和TestReporter参数。

例如：

class MethodParametersTest {@Test// implicitly uses TestInfoParameterResolver to provide testInfovoid testWithBuiltIntParameterResolver( TestInfo testInfo ) {// ...}@Test@ExtendWith( CustomEnvironmentParameterResolver.class )// explicit resolver declared, could also be placed at class levelvoid testWithCustomParameterResolver( CustomEnvironment environment ) {// ...}
}

如果在运行时找不到匹配的参数解析器，则引擎将通过相应的消息使测试失败。

该文档指出，有计划提供其他扩展，其中还包括一个用于动态测试注册的扩展。有了这个扩展，就有可能进行参数化测试。考虑到测试方法已经接受了参数，参数化测试似乎也可以在方法级别上使用。