JUnit5实战：测试Java项目的全新框架

需积分: 10 116 浏览量更新于2024-07-19 收藏 2.39MB PDF 举报

"这篇文档是关于Junit 5的用户指南，由多个作者共同编写，涵盖了Junit 5的基本信息、安装、测试编写、运行测试以及扩展模型等内容。" JUnit5是Java编程语言中广泛使用的单元测试框架的最新版本，相较于Junit 4，它引入了大量新特性和改进。文档首先概述了JUnit5是什么，它支持从Java 8到Java 17的多个版本，并提供了获取帮助的途径。在安装部分，文档提到了依赖元数据和依赖关系图，这对于在构建系统中集成JUnit5至关重要。此外，还给出了JUnit Jupiter样例项目，帮助开发者快速上手。编写测试是文档的核心部分。JUnit5提供了丰富的注解，如@Test、@Before、@After等，使得测试类和方法的定义更加简洁。标准的测试类可以通过注解进行配置，而显示名称功能让测试结果更易读。断言机制进行了增强，支持更复杂的条件判断。假设（Assumptions）允许在特定条件下跳过测试，避免了不必要的执行。测试可以被禁用，或者通过标记和过滤进行分组执行。测试实例生命周期控制确保了每个测试方法的独立性，而嵌套测试则允许组织更复杂的测试结构。依赖注入对构造函数和方法的支持使得测试更灵活，测试接口和默认方法使得代码重用成为可能。重复测试可方便地多次运行同一个测试，参数化测试则允许为测试方法提供多种输入组合。测试模板和动态测试提供了更高级的测试构造方式。运行测试方面，文档介绍了IDE支持，如IntelliJ IDEA和Eclipse的集成，以及构建工具如Maven和Gradle的配置。ConsoleLauncher使得从命令行运行测试变得简单，同时，JUnit4可以用来启动JUnit平台，兼容旧版的测试逻辑。配置参数允许自定义测试运行时的行为。最后，扩展模型部分介绍了如何自定义JUnit5的行为，包括注册扩展、条件性测试执行、测试实例后处理以及参数化重用等。这使得JUnit5成为一个高度可扩展的框架，可以根据具体需求定制测试行为。总体来说，这份文档详细地介绍了JUnit5的各个方面，是学习和使用JUnit5进行单元测试的宝贵资源。无论是新手还是有经验的开发者，都能从中找到所需的信息，提升测试效率和代码质量。

import org.junit.jupiter.api.Disabled;

import org.junit.jupiter.api.Test;

@Disabled

class DisabledClassDemo {

Ê @Test

Ê void testWillBeSkipped() {

Ê }

}

And here’s a test case with a disabled test method.

import org.junit.jupiter.api.Disabled;

import org.junit.jupiter.api.Test;

class DisabledTestsDemo {

Ê @Disabled

Ê @Test

Ê void testWillBeSkipped() {

Ê }

Ê @Test

Ê void testWillBeExecuted() {

Ê }

}

3.7. Tagging and Filtering

Test classes and methods can be tagged. Those tags can later be used to filter test discovery and

execution.

3.7.1. Syntax Rules for Tags

• A tag must not be null or blank.

• A trimmed tag must not contain whitespace.

• A trimmed tag must not contain ISO control characters.

• A trimmed tag must not contain any of the following reserved characters.

◦ ,, (, ), &, |, !



In the above context, "trimmed" means that leading and trailing whitespace

characters have been removed.

import org.junit.jupiter.api.Tag;

import org.junit.jupiter.api.Test;

@Tag("fast")

@Tag("model")

class TaggingDemo {

Ê @Test

Ê @Tag("taxes")

Ê void testingTaxCalculation() {

Ê }

}

3.8. Test Instance Lifecycle

In order to allow individual test methods to be executed in isolation and to avoid unexpected side

effects due to mutable test instance state, JUnit creates a new instance of each test class before

executing each test method (see note below for what qualifies as a test method). This "per-method"

test instance lifecycle is the default behavior in JUnit Jupiter and is analogous to all previous

versions of JUnit.

If you would prefer that JUnit Jupiter execute all test methods on the same test instance, simply

annotate your test class with @TestInstance(Lifecycle.PER_CLASS). When using this mode, a new test

instance will be created once per test class. Thus, if your test methods rely on state stored in

instance variables, you may need to reset that state in @BeforeEach or @AfterEach methods.

The "per-class" mode has some additional benefits over the default "per-method" mode. Specifically,

with the "per-class" mode it becomes possible to declare @BeforeAll and @AfterAll on non-static

methods as well as on interface default methods. The "per-class" mode therefore also makes it

possible to use @BeforeAll and @AfterAll methods in @Nested test classes.

If you are authoring tests using the Kotlin programming language, you may also find it easier to

implement @BeforeAll and @AfterAll methods by switching to the "per-class" test instance lifecycle

mode.



In the context of test instance lifecycle a test method is any method annotated with

@Test, @RepeatedTest, @ParameterizedTest, @TestFactory, or @TestTemplate.

3.8.1. Changing the Default Test Instance Lifecycle

If a test class or test interface is not annotated with @TestInstance, JUnit Jupiter will use a default

lifecycle mode. The standard default mode is PER_METHOD; however, it is possible to change the

default for the execution of an entire test plan. To change the default test instance lifecycle mode,

simply set the junit.jupiter.testinstance.lifecycle.default configuration parameter to the name

of an enum constant defined in TestInstance.Lifecycle, ignoring case. This can be supplied as a

JVM system property, as a configuration parameter in the LauncherDiscoveryRequest that is passed to

the Launcher, or via the JUnit Platform configuration file (see Configuration Parameters for details).

For example, to set the default test instance lifecycle mode to Lifecycle.PER_CLASS, you can start

your JVM with the following system property.

-Djunit.jupiter.testinstance.lifecycle.default=per_class

Note, however, that setting the default test instance lifecycle mode via the JUnit Platform

configuration file is a more robust solution since the configuration file can be checked into a

version control system along with your project and can therefore be used within IDEs and your

build software.

To set the default test instance lifecycle mode to Lifecycle.PER_CLASS via the JUnit Platform

configuration file, create a file named junit-platform.properties in the root of the class path (e.g.,

src/test/resources) with the following content.

junit.jupiter.testinstance.lifecycle.default = per_class



Changing the default test instance lifecycle mode can lead to unpredictable results

and fragile builds if not applied consistently. For example, if the build configures

"per-class" semantics as the default but tests in the IDE are executed using "per-

method" semantics, that can make it difficult to debug errors that occur on the

build server. It is therefore recommended to change the default in the JUnit

Platform configuration file instead of via a JVM system property.

3.9. Nested Tests

Nested tests give the test writer more capabilities to express the relationship among several group

of tests. Here’s an elaborate example.

Nested test suite for testing a stack

import static org.junit.jupiter.api.Assertions.assertEquals;

import static org.junit.jupiter.api.Assertions.assertFalse;

import static org.junit.jupiter.api.Assertions.assertThrows;

import static org.junit.jupiter.api.Assertions.assertTrue;

import java.util.EmptyStackException;

import java.util.Stack;

import org.junit.jupiter.api.BeforeEach;

import org.junit.jupiter.api.DisplayName;

import org.junit.jupiter.api.Nested;

import org.junit.jupiter.api.Test;

@DisplayName("A stack")

class TestingAStackDemo {

Ê Stack<Object> stack;

Ê @DisplayName("returns the element when popped and is empty")

Ê void returnElementWhenPopped() {

Ê assertEquals(anElement, stack.pop());

Ê assertTrue(stack.isEmpty());

Ê }

Ê @Test

Ê @DisplayName("returns the element when peeked but remains not empty")

Ê void returnElementWhenPeeked() {

Ê assertEquals(anElement, stack.peek());

Ê assertFalse(stack.isEmpty());

Ê }

}



Only non-static nested classes (i.e. inner classes) can serve as @Nested test classes.

Nesting can be arbitrarily deep, and those inner classes are considered to be full

members of the test class family with one exception: @BeforeAll and @AfterAll

methods do not work by default. The reason is that Java does not allow static

members in inner classes. However, this restriction can be circumvented by

annotating a @Nested test class with @TestInstance(Lifecycle.PER_CLASS) (see Test

Instance Lifecycle).

3.10. Dependency Injection for Constructors and

Methods

In all prior JUnit versions, test constructors or methods were not allowed to have parameters (at

least not with the standard Runner implementations). As one of the major changes in JUnit Jupiter,

both test constructors and methods are now permitted to have parameters. This allows for greater

flexibility and enables Dependency Injection for constructors and methods.

ParameterResolver defines the API for test extensions that wish to dynamically resolve parameters at

runtime. If a test constructor or a @Test, @TestFactory, @BeforeEach, @AfterEach, @BeforeAll, or

@AfterAll method accepts a parameter, the parameter must be resolved at runtime by a registered

ParameterResolver.

There are currently three built-in resolvers that are registered automatically.

• TestInfoParameterResolver: if a method parameter is of type TestInfo, the

TestInfoParameterResolver will supply an instance of TestInfo corresponding to the current test

as the value for the parameter. The TestInfo can then be used to retrieve information about the

current test such as the test’s display name, the test class, the test method, or associated tags.

The display name is either a technical name, such as the name of the test class or test method,

or a custom name configured via @DisplayName.

TestInfo acts as a drop-in replacement for the TestName rule from JUnit 4. The following

demonstrates how to have TestInfo injected into a test constructor, @BeforeEach method, and

剩余100页未读，继续阅读

liwei55555

粉丝: 0
资源: 1

JUnit5实战：测试Java项目的全新框架

Junit 5中文帮助指南

junit5-r5.3.0

Junit5用户手册

软件测试junit5与junit4的区别

JUnit5中的依赖注入是如何工作的？请解释其工作机制并提供一个使用JUnit5进行依赖注入的示例。

如何正确的配置junit5

请描述JUnit5中的依赖注入机制，并给出一个使用JUnit5进行依赖注入的代码示例。

org.junit.jupiter.api.extension.parameterresolutionexception: no parameterresolver registered for parameter

junit-bom单元测试

如何在JUnit5中利用依赖注入机制提高测试的灵活性和效率？请结合代码示例进行说明。

最新资源