富阳做网站,用html做的零食网站,wordpress用户角色管理系统,专门做衣服的网站有哪些junit5和junit42月初#xff0c; JUnit 5#xff08;又名JUnit Lambda#xff09;团队发布了一个alpha版本。 由于JUnit 4是我工具箱中使用最多的项目之一#xff0c;因此我认为值得一看下一个主要版本。 我试用了最新版本#xff0c;并记下了我在这里发现值得注意的更改… 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 ) {// ...}TestExtendWith( CustomEnvironmentParameterResolver.class )// explicit resolver declared, could also be placed at class levelvoid testWithCustomParameterResolver( CustomEnvironment environment ) {// ...}
} 如果在运行时找不到匹配的参数解析器则引擎将通过相应的消息使测试失败。 该文档指出有计划提供其他扩展其中还包括一个用于动态测试注册的扩展。 有了这个扩展就有可能进行参数化测试。 考虑到测试方法已经接受了参数参数化测试似乎也可以在方法级别上使用。 向后兼容 为了缩小差距直到IDE本地支持JUnit 5为止有一个JUnit 4 Runner能够执行为JUnit 5编写的测试。使用RunWith(JUnit5.class)批注来运行测试类和测试套件。 通过该运行器可以并排运行JUnit 4和5测试类。 在单个测试中混合使用新旧概念当然是Rule的例如将Rule与ExtendWith等共存。 Mockito和AssertJ等测试实用程序将继续使用新版本而无需进行更改。 他们通过引发一个异常来与JUnit交互即使在JUnit 5中该异常仍然被认为是测试失败) JVM开放测试联盟 JUnit Lambda团队还为JVM建立了开放测试联盟 其目标是建立一个标准以促进测试框架断言库模拟库构建工具和IDE之间的交互。 主要目标是提供一个库该库定义测试框架例如JUnitTestNGSpock等要使用的一组通用异常以及断言库。 构建工具和IDE也将受益因为它们可以依赖相同的类型集而与测试框架无关。 可以以org.opentest4j库的形式获得实现草案您可以猜到它是JUnit 5使用的。 外表 我的印象是建立了新版本的基本概念。 诸如Test设置和拆卸注释之类的东西单个扩展模型的概念可能仍会保持当前形状。 但是许多细节似乎尚未解决API可能会发生变化我认为这在开发周期的现阶段是可以理解的。 API的每个部分都标有API注释 以指示其稳定性。 如果这篇文章引起了您的兴趣并且您可能希望浏览文档以获取更多信息那么还有很多值得探索的地方例如 用于过滤测试执行的标签 嵌套测试以对测试进行分组并表达测试组之间的关系 可扩展的思路进行测试验证规则 如Test和BeforeEach不应该在同样的方法进行 在运行时动态注册测试 注释有助于并行运行测试 第一个里程碑计划于2016年第一季度末发布。 此处提供了此发行版中要解决的项目的暂定清单。 翻译自: https://www.javacodegeeks.com/2016/02/junit-5-first-look-next-generation-junit.htmljunit5和junit4
