Java程序的单元测试

# 一、单元测试简介

# 1. 单元测试的概念

单元测试（Unit Testing）是指对软件中的最小可测试单元进行检查和验证的过程。对于面向对象编程来说，一个类可以视为一个测试单元；而对于函数式编程，单个函数或过程则通常构成一个单元。单元测试的主要目的是确保每个单独的组件都能按照预期正常工作。

在Java程序中，单元测试通常由开发者编写，它涵盖了各种可能的输入、边界条件以及异常情况，并且会验证代码的行为是否符合设计要求。理想情况下，这些测试应当独立于其他代码部分，以便准确地识别问题所在。

# 2. 单元测试的重要性

单元测试对于提高软件质量具有至关重要的作用：

早期发现问题：通过频繁执行单元测试，可以在开发周期的早期阶段发现并修复缺陷，避免了后期更复杂和昂贵的调试与维护。
促进设计改进：良好的单元测试能够反映出代码结构上的不足，从而促使开发者优化其设计，使得系统更加模块化、松耦合。
增强信心：拥有全面覆盖的单元测试集可以使团队成员在做出变更时更有信心，因为他们知道如果引入了新的错误，测试将很快捕捉到。
文档价值：单元测试实际上也充当了一种活文档的角色，展示了如何正确使用API或类库，有助于新加入项目的人员快速上手。
支持重构：当需要重构代码以改善性能或者添加新特性时，已有的单元测试可以作为安全网，保证改动不会破坏现有功能。

# 3. 单元测试的特点

单元测试具备以下几个显著特点：

自动化：单元测试是自动化的，这意味着它们可以被集成到持续集成系统中，在每次构建时自动运行，无需人工干预。
快速反馈：由于只针对单个组件，因此单元测试应该执行得非常快，提供即时反馈给开发者。
隔离性：每个单元测试都是独立的，不依赖外部环境或者其他测试的结果。这保证了即使某些测试失败，也不会影响其他测试的准确性。
重复性：同样的测试可以在不同环境中多次运行，结果应当保持一致，不受时间地点的影响。
细粒度：专注于测试单一的功能点或行为，而不是整个应用程序的工作流程。
确定性：对于相同的输入，总是产生相同的结果，除非代码发生了更改。这种一致性让开发者能够信赖测试结果的有效性。

# 二、Java单元测试框架

# 1. JUnit框架介绍

# a. JUnit的历史与发展

JUnit 是一个专门为 Java 编程语言设计的开源单元测试框架。它由 Erich Gamma 和 Kent Beck 在 1997 年创建，最初是受 Smalltalk 单元测试框架的影响。JUnit 的出现极大地推动了测试驱动开发（TDD）方法论的发展，并成为 Java 社区中最受欢迎和广泛使用的单元测试工具之一。

JUnit 经历了多个版本的迭代：

JUnit 3：早期版本使用继承机制来定义测试类，所有的测试方法都必须以 test 开头，并且返回类型为 void。
JUnit 4：引入了基于注解的测试方式，比如 @Test，这使得编写测试更加灵活和直观。还增加了对参数化测试的支持，允许通过不同的数据集运行相同的测试逻辑。
JUnit 5：这是一个重大的更新，它不仅增强了功能，而且还改善了 API 设计，使其更易于扩展。JUnit 5 分为三个模块：
- JUnit Platform：提供了一个通用的基础结构，可以在 JVM 上启动测试执行引擎。
- JUnit Jupiter：这是 JUnit 5 新的编程模型和扩展模型，包括了所有新的注解和 API。
- JUnit Vintage：用于向后兼容旧版 JUnit 3 和 4 测试。

随着版本的演进，JUnit 不断改进其性能、稳定性和易用性，同时保持与社区需求同步发展。

# b. JUnit的核心概念

JUnit 框架围绕几个关键概念构建，这些概念帮助开发者有效地组织和管理他们的测试代码：

测试类（Test Class）：包含一系列相关测试方法的 Java 类。每个测试类通常对应于被测系统的一个特定组件或模块。
测试方法（Test Method）：在测试类中定义的方法，它们代表单个测试案例。测试方法应当是无参的，并返回 void。从 JUnit 4 开始，可以使用 @Test 注解来标记测试方法。
断言（Assertions）：用来验证程序行为是否符合预期的关键构造。JUnit 提供了一组静态方法如 assertEquals, assertTrue 等，用于比较实际结果与预期结果。JUnit 5 引入了更加丰富的断言库，例如支持流式断言（Fluent Assertions）和组合断言（Composite Assertions），允许在一个步骤中检查多个条件。
测试套件（Test Suite）：将多个测试类组合在一起执行。JUnit 4 使用 @Suite.SuiteClasses 来指定要包含的测试类；而在 JUnit 5 中，则可以通过 @SelectClasses 或者 @SelectPackages 注解选择测试类或包。
生命周期回调（Lifecycle Callbacks）：JUnit 支持在测试执行的不同阶段调用特定的方法。例如，在 JUnit 4 中有 @Before 和 @After 注解分别用于在每个测试方法之前和之后执行的初始化和清理工作；JUnit 5 则提供了更多的生命周期管理选项，如 @BeforeEach, @AfterEach, @BeforeAll, 和 @AfterAll，以及动态测试注册等功能。
异常测试（Exception Testing）：JUnit 允许开发者指定期望抛出的异常类型，确保当某些条件不满足时会触发相应的异常。JUnit 4 可以通过 expected 属性在 @Test 注解中声明；JUnit 5 提供了更为直观的方式，如 assertThrows 方法。
超时测试（Timeout Testing）：JUnit 5 引入了超时属性，允许设定一个最大执行时间，如果测试在这个时间内没有完成，则认为失败。
参数化测试（Parameterized Tests）：JUnit 4 和 5 都支持参数化测试，允许同一个测试方法接收不同参数值进行多次执行。JUnit 5 为此提供了更简洁的语法和更好的灵活性。

通过掌握这些核心概念，开发者可以更好地利用 JUnit 框架来进行高效且全面的单元测试，从而提高软件的质量和可靠性。

# 2. TestNG框架概述

# a. TestNG的独特特性

TestNG（Test Next Generation）是一个受JUnit和NUnit启发的测试框架，但相比而言它提供了更多的功能和灵活性。以下是TestNG的一些独特特性：

灵活的测试配置：TestNG允许通过XML文件或注解来配置测试套件、类和方法。这使得组织和运行测试更加直观，并且可以根据需要轻松调整测试环境。
参数化测试：TestNG内置了强大的参数化功能，可以通过数据提供者（DataProvider）为测试方法传递参数，支持多组数据驱动测试，这对于需要反复执行相同逻辑但输入不同的场景非常有用。
依赖性测试：TestNG允许定义测试方法之间的依赖关系，确保某些测试只有在其依赖的测试成功之后才会被执行。这一特性对于测试顺序有严格要求的情况特别有价值。
并行测试执行：TestNG能够并行地运行测试用例、类甚至整个套件，极大地提高了测试效率，尤其是在大型项目中可以显著缩短构建时间。
丰富的注解集：除了常见的@Test之外，TestNG还提供了诸如@BeforeSuite, @AfterSuite, @BeforeClass, @AfterClass, @BeforeMethod, @AfterMethod等生命周期注解，以及@DataProvider, @Parameters等用于参数化的注解，使测试代码的组织更为清晰。
支持多种类型测试：TestNG不仅限于单元测试，还可以进行集成测试、功能测试等多种类型的测试，适应更广泛的测试需求。
分布式测试：TestNG与CI/CD工具如Maven, Gradle良好集成，也支持分布式测试，即在多个机器上同时运行测试。
详细的报告和日志：TestNG生成详尽的HTML格式测试报告，便于查看测试结果；并且可以通过插件系统自定义报告样式。
良好的异常处理：TestNG允许指定期望的异常，当测试方法抛出指定异常时认为测试通过，这有助于验证错误条件下的行为。

# b. 与JUnit的比较

尽管JUnit和TestNG都是优秀的Java测试框架，但它们之间存在一些关键差异：

复杂度 vs 简洁性：JUnit的设计理念是保持简单易用，而TestNG则更侧重于功能性和灵活性。因此，在选择框架时需根据项目的具体需求权衡这两点。
测试配置：JUnit主要依靠注解来进行测试配置，而TestNG既支持注解也支持通过外部XML文件进行配置，后者更适合大型项目中的复杂测试场景。
参数化和支持的数据范围：虽然JUnit 4和5都引入了一定程度上的参数化支持，但在灵活性和便利性方面，TestNG的数据提供者机制更为优越，特别是在处理大量测试数据时。
依赖管理：TestNG原生支持测试方法间的依赖关系，而JUnit不直接提供这种功能，开发者需要自行实现或借助第三方库。
并发测试：TestNG对并行测试的支持比JUnit更为成熟，配置更加简便，性能也更优。
测试类型：JUnit主要用于单元测试，而TestNG因其更广泛的功能集，适用于从单元测试到端到端测试的各种测试类型。
社区和支持：JUnit作为历史悠久的测试框架，拥有庞大的用户群体和活跃的社区支持。然而，TestNG也有其特定的应用场景和忠实用户群，特别是在那些需要高级特性的项目中。

综上所述，选择哪个框架取决于项目的实际需求和个人偏好。对于大多数标准的单元测试任务，JUnit可能已经足够；但如果涉及到更复杂的测试流程或者需要额外的功能，那么TestNG可能是更好的选择。

# 三、编写第一个JUnit测试案例

# 1. 设置开发环境（Maven）

为了使用 JUnit 5 进行单元测试，首先需要设置一个合适的开发环境。这里我们将使用 Maven 来管理项目依赖，并配置必要的构建工具。

安装 JDK：确保您的计算机上已经安装了 Java Development Kit (JDK)，因为 Maven 和 JUnit 都是基于 Java 的工具。
安装 Maven：下载并安装 Apache Maven。请参考官方文档获取最新版本和安装指南。
创建 Maven 项目：可以通过 IDE（如 IntelliJ IDEA 或 Eclipse）创建一个新的 Maven 项目，或者通过命令行执行 mvn archetype:generate 命令来生成项目结构。
添加 JUnit 5 依赖：在项目的 pom.xml 文件中添加 JUnit Jupiter API 和 Engine 作为依赖项。以下是示例代码：

<dependencies>
    <!-- JUnit 5 -->
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-api</artifactId>
        <version>5.9.2</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-engine</artifactId>
        <version>5.9.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

# 2. 创建简单的Java类

接下来，我们创建一个简单的 Java 类来进行测试。假设我们要测试一个名为 Calculator 的类，它包含基本的加法方法。

// src/main/java/com/example/calculator/Calculator.java
package com.example.calculator;

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }
}

# 3. 编写测试代码(Junit 5)

# a. 使用注解标记测试方法

JUnit 5 提供了一系列注解来帮助组织和定义测试逻辑。以下是几个常用的注解：

@Test：标记一个方法为测试方法。
@BeforeEach：标记的方法将在每个测试方法之前运行，通常用于初始化资源。
@AfterEach：标记的方法将在每个测试方法之后运行，通常用于清理资源。
@BeforeAll：标记的方法将在所有测试方法之前只运行一次，适用于一次性初始化操作。
@AfterAll：标记的方法将在所有测试方法之后只运行一次，适合做最终清理工作。
@Disabled：禁用某个测试方法或类，相当于暂时忽略这些测试。
@DisplayName：可以通过空格、特殊字符甚至表情符号声明自定义显示名称，这些名称将显示在测试报告、测试运行器和 IDE 中。
@Tag：为测试添加标签，方便分类和筛选执行特定标签的测试。

下面是一个带有上述注解的测试类的例子：

// src/test/java/com/example/calculator/CalculatorTest.java
package com.example.calculator;

import org.junit.jupiter.api.*;

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

class CalculatorTest {

    private Calculator calculator;

    @BeforeEach
    void setUp() {
        calculator = new Calculator();
    }

    @Test
    void testAddition() {
        assertEquals(4, calculator.add(2, 2), "2 + 2 should equal 4");
    }

    @AfterEach
    void tearDown() {
        // 清理操作，如果有的话
    }

    @BeforeAll
    static void beforeAllTests() {
        System.out.println("Starting all tests...");
    }

    @AfterAll
    static void afterAllTests() {
        System.out.println("Finished all tests.");
    }
}

# b. 断言（Assertions）的使用

JUnit 5 提供了多种类型的断言来帮助开发者验证测试结果是否符合预期。

JUnit 5 的断言机制大致分为以下几大类：

标准断言（Standard Assertions）
- 这是最基本和最常用的断言类型。它们提供了简单直接的方法来验证预期结果与实际结果是否一致。
- 常用方法：
  - assertEquals(expected, actual)：检查两个值是否相等。
  - assertTrue(condition) 和 assertFalse(condition)：分别用于验证条件为真或假。
  - assertNull(object) 和 assertNotNull(object)：用于验证对象是否为空或非空。
  - assertSame(expected, actual) 和 assertNotSame(unexpected, actual)：用于验证两个引用是否指向同一个对象实例。
异常断言（Exception Assertions）
- JUnit 5 提供了专门用于测试代码是否抛出预期异常的功能。
- 常用方法：
  - assertThrows(Class<? extends Throwable> expectedType, Executable executable)：执行给定的代码块，并验证它是否抛出了指定类型的异常。
超时断言（Timeout Assertions）
- 可以设定一个最大执行时间，如果测试在这个时间内没有完成，则认为失败。
- 使用方式：
  - assertTimeout(Duration timeout, Executable executable)：确保测试在指定的时间内完成。
  - assertTimeoutPreemptively(Duration timeout, Executable executable)：提前终止长时间运行的任务。
组合断言（Composite Assertions）
- 允许在一个步骤中执行多个断言操作，所有断言都会被执行，即使其中一个失败。
- 常用方法：
  - assertAll(Executable... executables) 或者 assertAll(String displayName, Executable... executables)：允许将多个断言组合在一起，提供更清晰的错误报告。

示例代码：

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

@Test
void testStandardAssertions() {
    Calculator calculator = new Calculator();
    
    assertEquals(4, calculator.add(2, 2), "2 + 2 should equal 4");
    assertTrue(calculator.add(3, 2) > 4, "3 + 2 should be greater than 4");
    assertFalse(calculator.add(-1, -1) > 0, "-1 + (-1) should not be greater than 0");
    assertNull(null, "Should be null");
    assertNotNull(new Object(), "Should not be null");
}

# AssertJ库

AssertJ 是一个第三方断言库，它提供了更加流畅、易于阅读且功能丰富的 API。相比于 JUnit 5 内置的断言，AssertJ 支持更多的断言类型，并且其语法设计使得代码更具表达力。

安装 AssertJ：

首先，在 Maven 的 pom.xml 文件中添加 AssertJ 依赖：

<dependency>
    <groupId>org.assertj</groupId>
    <artifactId>assertj-core</artifactId>
    <version>3.24.2</version>
    <scope>test</scope>
</dependency>

使用 AssertJ 进行断言：

import static org.assertj.core.api.Assertions.*;

@Test
void testAdditionWithAssertJ() {
    Calculator calculator = new Calculator();
    
    // 使用 AssertJ 进行断言
    assertThat(calculator.add(2, 2))
        .isEqualTo(4)               // 等于 4
        .isPositive()               // 是正数
        .isGreaterThan(0);          // 大于 0
    
    // 对集合进行断言
    List<Integer> numbers = Arrays.asList(1, 2, 3);
    assertThat(numbers)
        .hasSize(3)                 // 集合大小为 3
        .contains(1, 2, 3)         // 包含这些元素
        .doesNotContain(4);         // 不包含 4
}

通过上述不同类型的断言，您可以根据具体需求选择最适合的方式来编写清晰、可靠的单元测试。JUnit 5 和 AssertJ 的结合使用能够显著提高测试代码的质量和可维护性。

# 四、高级单元测试技术

# 1. 参数化测试

参数化测试是 JUnit 5 中的一项强大功能，它允许您通过不同的输入数据多次执行同一个测试方法。这不仅减少了重复代码，还提高了测试覆盖率。以下是关于如何在 JUnit 5 中实现参数化测试的详细说明。

# a. 使用参数

要创建参数化测试，首先需要定义一个带有参数的方法，并使用 @ParameterizedTest 注解来标记该方法。然后，选择合适的数据源为这些参数提供值。每个参数可以是一个基本类型、对象或数组等。

# b. 数据来源

JUnit 5 提供了多种注解来指定参数化测试的数据来源，以下是一些常用的注解及其用法：

# @ValueSource

@ValueSource 是最简单的数据提供方式之一，它可以直接为测试方法提供一组固定值。适用于基本类型和字符串。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;

class ValueSourceExample {

    @ParameterizedTest
    @ValueSource(strings = {"hello", "world"})
    void testWithSimpleValues(String argument) {
        assertNotNull(argument);
    }
}

# 无效源和空源

在 JUnit 5 的参数化测试中，处理 无效源 和空源是确保测试全面性和健壮性的重要部分。这些特性允许您涵盖边界情况和异常条件，从而增强测试的覆盖范围。以下是有关如何使用 @NullSource、@EmptySource 等注解的具体介绍。

@NullSource

@NullSource 注解用于为测试方法提供 null 作为参数值。这对于验证代码是否能够正确处理空输入非常有用，尤其是在检查 NullPointerException 或其他与空值相关的错误时。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.NullSource;

class NullSourceExample {

    @ParameterizedTest
    @NullSource
    void testWithNullArgument(String argument) {
        assertNull(argument);
    }
}

在这个例子中，testWithNullArgument 方法将被调用一次，并且参数 argument 将为 null。这有助于确保您的代码可以在接收到空值时正常工作或抛出适当的异常。

@EmptySource

@EmptySource 注解用于为字符串类型的参数提供空字符串（""）。这对于测试逻辑是否能正确处理空白输入非常重要，例如验证用户输入不能为空等场景。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.EmptySource;

class EmptySourceExample {

    @ParameterizedTest
    @EmptySource
    void testWithEmptyStringArgument(String argument) {
        assertEquals("", argument);
    }
}

这里，testWithEmptyStringArgument 方法将被调用一次，参数 argument 将是一个空字符串。通过这种方式，您可以确保代码能够适当地响应这种特殊情况。

# @EnumSource

@EnumSource 是 JUnit 5 中用于参数化测试的一个强大工具，它允许您从枚举类型中获取参数值。这使得您可以轻松地遍历整个枚举集或选择特定的枚举常量来进行测试。以下是关于 @EnumSource 的更详细说明，包括其各种选项和用法示例。

# 基本用法

最简单的形式是直接使用 @EnumSource 注解，并指定要使用的枚举类。JUnit 将自动为该枚举中的每个常量创建一个测试案例。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.EnumSource;

enum Color { RED, GREEN, BLUE }

class EnumSourceExample {

    @ParameterizedTest
    @EnumSource(Color.class)
    void testWithEnumValues(Color color) {
        assertNotNull(color);
    }
}

在这个例子中，testWithEnumValues 方法将被调用三次，分别传入 Color.RED, Color.GREEN, 和 Color.BLUE。

# 指定模式（Modes）

@EnumSource 提供了多种模式来控制如何选择枚举常量：

ALL：默认模式，遍历枚举中的所有常量。
MATCH_ALL：仅选择名称匹配给定正则表达式的枚举常量。
MATCH_ANY：选择名称至少有一个匹配给定正则表达式的枚举常量。
EXCLUDE：排除名称匹配给定正则表达式的枚举常量。

示例：

@ParameterizedTest
@EnumSource(value = Color.class, mode = EnumSource.Mode.MATCH_ALL, names = "RED|BLUE")
void testWithSelectedEnumValues(Color color) {
    assertTrue(color == Color.RED || color == Color.BLUE);
}

@ParameterizedTest
@EnumSource(value = Color.class, mode = EnumSource.Mode.EXCLUDE, names = "GREEN")
void testExcludingGreen(Color color) {
    assertNotEquals(Color.GREEN, color);
}

在第一个测试方法中，只有名称为 RED 或 BLUE 的枚举常量会被选中；而在第二个测试方法中，GREEN 被排除在外。

# 使用 `names` 和 `ignoreCase`

您可以使用 names 属性来明确列出希望包含的枚举常量名称。此外，还可以通过设置 ignoreCase=true 来忽略大小写差异。

示例：

@ParameterizedTest
@EnumSource(value = Color.class, names = {"red", "blue"}, ignoreCase = true)
void testCaseInsensitiveEnumValues(Color color) {
    assertTrue(color == Color.RED || color == Color.BLUE);
}

这里，即使提供的名称是小写的 "red" 和 "blue"，它们也会与对应的枚举常量匹配，因为启用了大小写不敏感比较。

# 结合其他数据源

@EnumSource 可以与其他参数提供注解一起使用，以创建更复杂的测试场景。例如，您可以结合 @NullSource、@EmptySource 等来涵盖更多边界情况。

示例：

@ParameterizedTest
@EnumSource(Color.class)
@NullSource
void testWithEnumAndNull(Color color) {
    if (color != null) {
        assertNotNull(color.name());
    } else {
        assertNull(color);
    }
}

在这个例子中，测试不仅会覆盖所有枚举常量，还会额外处理一次 null 输入的情况。

# @MethodSource

@MethodSource 允许从静态方法中获取参数。该方法必须返回一个实现了 Stream, Iterator, Iterable, 或者数组的对象。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.MethodSource;

class MethodSourceExample {

    static Stream<String> provideStrings() {
        return Stream.of("apple", "banana", "orange");
    }

    @ParameterizedTest
    @MethodSource("provideStrings")
    void testWithMethodSource(String fruit) {
        assertTrue(fruit.length() > 0);
    }
}

也可以引入外部static工厂方法：

@MethodSource("example.StringsProviders#tinyStrings")

# @FieldSource

@FieldSource允许您引用测试类或外部类的一个或多个字段。

@ParameterizedTest
@FieldSource("listOfFruits")
void singleFieldSource(String fruit) {
    assertFruit(fruit);
}

static final List<String> listOfFruits = Arrays.asList("apple", "banana");

# @CsvSource

@CsvSource 可以将逗号分隔的值作为参数传递给测试方法，非常适合处理多参数的情况。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;

class CsvSourceExample {

    @ParameterizedTest
    @CsvSource({
        "1, 2, 3",
        "4, 5, 9"
    })
    void testWithCsvSource(int first, int second, int expectedResult) {
        assertEquals(expectedResult, first + second);
    }
}

@ParameterizedTest(name = "[{index}] {arguments}")
@CsvSource(useHeadersInDisplayName = true, textBlock = """
        FRUIT,         RANK
        apple,         1
        banana,        2
        'lemon, lime', 0xF1
        strawberry,    700_000
        """)
void testWithCsvSource(String fruit, int rank) {
    // ...
}

# @CsvFileSource

@CsvFileSource 类似于 @CsvSource，但它从外部 CSV 文件加载数据，这对于大量测试数据特别有用。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvFileSource;

class CsvFileSourceExample {

    @ParameterizedTest
    @CsvFileSource(resources = "/data.csv", numLinesToSkip = 1)
    void testWithCsvFileSource(int first, int second, int expectedResult) {
        assertEquals(expectedResult, first + second);
    }
}

# @ArgumentsSource

@ArgumentsSource 使您可以自定义数据提供者类，该类必须实现 ArgumentsProvider 接口。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ArgumentsSource;

class ArgumentsSourceExample {

    @ParameterizedTest
    @ArgumentsSource(MyArgumentsProvider.class)
    void testWithCustomArgumentsProvider(int arg) {
        assertTrue(arg > 0);
    }
}

class MyArgumentsProvider implements ArgumentsProvider {
    @Override
    public Stream<? extends Arguments> provideArguments(ExtensionContext context) throws Exception {
        return Stream.of(Arguments.of(1), Arguments.of(2));
    }
}

# 使用可重复注释的多个来源

JUnit 5 支持在一个测试方法上应用多个参数提供注解，从而组合不同的数据源。

示例：

@ParameterizedTest
@ValueSource(strings = {"foo", "bar"})
@CsvSource({"baz,qux", "quux,corge"})
void testWithMultipleSources(String first, String second) {
    // 测试逻辑
}

# c. 参数转换

在 JUnit 5 中，参数化测试的一个重要特性是能够自动处理多种常见的参数类型转换。然而，在某些情况下，默认的转换机制可能无法满足特定的需求。这时，您可以通过实现 ArgumentConverter 接口来自定义参数转换逻辑。下面将详细介绍如何使用和自定义参数转换。

# 默认参数转换

JUnit 5 内置了对许多常见类型的自动转换支持，包括但不限于：

基本数据类型（如 int, long, boolean 等）
包装类（如 Integer, Long, Boolean 等）
字符串
枚举
日期时间类型（如 LocalDate, LocalTime, LocalDateTime）

这意味着，如果您提供的参数是一个字符串，并且目标参数类型是可以从字符串解析出来的类型，JUnit 会自动进行转换。

示例：

@ParameterizedTest
@ValueSource(strings = {"1", "2", "3"})
void testWithIntegers(int number) {
    assertTrue(number > 0);
}

在这个例子中，虽然提供了字符串形式的数字作为输入，但它们会被自动转换为 int 类型并传递给测试方法。

# 自定义参数转换

当默认的转换机制不足以应对复杂的业务逻辑时，您可以创建自己的转换器。要做到这一点，需要实现 ArgumentConverter 接口，并重写其唯一的抽象方法 convert。此方法接收原始参数值（通常是 String），并返回转换后的对象。

步骤：

创建转换器类：实现 ArgumentConverter 接口，并指定要转换的目标类型。
实现 convert 方法：编写具体的转换逻辑。
应用转换器：通过 @ConvertWith 注解将转换器应用到测试方法的参数上。

示例：

假设我们有一个表示颜色的自定义类 ColorDTO，它包含一个表示颜色名称的字段 name 和一个 RGB 值的字段 rgb。我们可以创建一个转换器来将颜色名称字符串转换为 ColorDTO 对象。

import org.junit.jupiter.params.converter.ArgumentConversionException;
import org.junit.jupiter.params.converter.SimpleArgumentConverter;

public class ColorDTOConverter extends SimpleArgumentConverter {

    @Override
    protected Object convert(Object source, Class<?> targetType) throws ArgumentConversionException {
        if (targetType.isAssignableFrom(ColorDTO.class)) {
            String colorName = (String) source;
            // 根据颜色名称创建 ColorDTO 实例
            return createColorDTO(colorName);
        }
        throw new ArgumentConversionException("Cannot convert " + source.getClass() + " to " + targetType);
    }

    private ColorDTO createColorDTO(String colorName) {
        // 这里可以添加更复杂的逻辑，例如从数据库或文件加载颜色信息
        switch (colorName.toLowerCase()) {
            case "red":
                return new ColorDTO("Red", 0xFF0000);
            case "green":
                return new ColorDTO("Green", 0x00FF00);
            case "blue":
                return new ColorDTO("Blue", 0x0000FF);
            default:
                throw new IllegalArgumentException("Unknown color: " + colorName);
        }
    }
}

// ColorDTO 类定义
class ColorDTO {
    private final String name;
    private final int rgb;

    public ColorDTO(String name, int rgb) {
        this.name = name;
        this.rgb = rgb;
    }

    // Getters and other methods...
}

接下来，在测试方法中使用 @ConvertWith 来应用这个转换器：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;

class CustomConversionExample {

    @ParameterizedTest
    @ValueSource(strings = {"Red", "Green", "Blue"})
    void testWithCustomConvertedArguments(@ConvertWith(ColorDTOConverter.class) ColorDTO color) {
        assertNotNull(color);
        System.out.println("Testing color: " + color.getName());
    }
}

# 使用 `SimpleArgumentConverter`

为了简化实现，JUnit 提供了一个名为 SimpleArgumentConverter 的辅助类，它是 ArgumentConverter 的一个简单实现。通过继承 SimpleArgumentConverter，您可以省去一些模板代码，只需专注于实际的转换逻辑。

示例：

public class SimplifiedColorDTOConverter extends SimpleArgumentConverter {

    @Override
    protected Object convert(Object source, Class<?> targetType) throws ArgumentConversionException {
        if (targetType.isAssignableFrom(ColorDTO.class)) {
            String colorName = (String) source;
            return createColorDTO(colorName);
        }
        throw new ArgumentConversionException("Unsupported type conversion");
    }

    private ColorDTO createColorDTO(String colorName) {
        // 同上...
    }
}

# 组合使用多个转换器

有时，您可能希望同时应用多个转换器来处理同一个参数。JUnit 允许在一个参数上标注多个 @ConvertWith 注解，从而依次调用这些转换器。

示例：

@ParameterizedTest
@ValueSource(strings = {"RED", "GREEN", "BLUE"})
void testWithMultipleConverters(
        @ConvertWith(UpperCaseConverter.class)
        @ConvertWith(ColorDTOConverter.class) ColorDTO color) {
    assertNotNull(color);
    System.out.println("Testing color: " + color.getName());
}

// 上下文无关的转换器，比如将字符串转为大写
public class UpperCaseConverter extends SimpleArgumentConverter {

    @Override
    protected Object convert(Object source, Class<?> targetType) throws ArgumentConversionException {
        if (source instanceof String && String.class.isAssignableFrom(targetType)) {
            return ((String) source).toUpperCase();
        }
        throw new ArgumentConversionException("Cannot convert to uppercase string");
    }
}

# d. 参数聚合

# ArgumentsAccessor

ArgumentsAccessor 是 JUnit 5 提供的一个工具类，它允许您以索引方式访问传递给测试方法的参数。当您有多个参数并且希望在测试中灵活地引用它们时，ArgumentsAccessor 就显得特别有用。

示例：

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.MethodSource;
import org.junit.jupiter.api.function.Executable;

import java.util.stream.Stream;

class ArgumentsAccessorExample {

    static Stream<Arguments> provideData() {
        return Stream.of(
            Arguments.of(1, 2, 3),
            Arguments.of(4, 5, 9)
        );
    }

    @ParameterizedTest
    @MethodSource("provideData")
    void testWithArgumentsAccessor(ArgumentsAccessor arguments) {
        int first = arguments.getInteger(0);
        int second = arguments.getInteger(1);
        int expectedResult = arguments.getInteger(2);

        assertEquals(expectedResult, first + second);
    }
}

在这个例子中，provideData 方法提供了一组参数，而 testWithArgumentsAccessor 测试方法接收一个 ArgumentsAccessor 对象作为参数。然后，可以通过索引从 ArgumentsAccessor 中获取各个参数值进行断言。

# 自定义聚合器

JUnit 5 还允许您创建自定义的参数聚合器，以便将多个参数转换为一个特定类型的对象。这通常涉及到实现 ArgumentsAggregator 接口，并将其应用到测试方法上。

步骤：

实现 ArgumentsAggregator 接口：这个接口要求您实现 aggregateArguments 方法，该方法接受一个 ArgumentsAccessor 和一个 ParameterContext，并返回一个目标类型的对象。
定义注解：创建一个新的注解（例如 @AggregateWith），并将其实现类指定为 ArgumentsAggregator 的具体实现。
应用注解：在测试方法的参数上使用自定义注解，以指示应如何聚合参数。

示例：

假设我们有一个表示矩形的类 Rectangle，它由两个整数（宽度和高度）构成。我们可以创建一个自定义聚合器来将这两个参数组合成一个 Rectangle 对象。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.CsvSource;
import org.junit.jupiter.params.aggregator.AggregateWith;
import org.junit.jupiter.params.aggregator.ArgumentsAggregationException;
import org.junit.jupiter.params.aggregator.ArgumentsAggregator;

import java.util.stream.Stream;

// 定义矩形类
class Rectangle {
    private final int width;
    private final int height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    public int getWidth() {
        return width;
    }

    public int getHeight() {
        return height;
    }

    public int getArea() {
        return width * height;
    }
}

// 实现 ArgumentsAggregator 接口
class RectangleAggregator implements ArgumentsAggregator {

    @Override
    public Object aggregateArguments(ArgumentsAccessor arguments, ParameterContext context) throws ArgumentsAggregationException {
        int width = arguments.getInteger(0);
        int height = arguments.getInteger(1);
        return new Rectangle(width, height);
    }
}

// 创建自定义注解
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
@AggregateWith(RectangleAggregator.class)
@interface AggregateToRectangle {
    Class<? extends ArgumentsAggregator> value();
}

// 使用自定义聚合器的测试
class CustomAggregatorExample {

    @ParameterizedTest
    @CsvSource({
        "2, 3",
        "4, 5"
    })
    void testRectangleArea(@AggregateToRectangle(RectangleAggregator.class) Rectangle rectangle) {
        assertTrue(rectangle.getArea() > 0);
    }
}

在这个例子中：

RectangleAggregator 类实现了 ArgumentsAggregator 接口，并定义了如何将两个整数参数转换为 Rectangle 对象。
@AggregateToRectangle 注解指定了要使用的聚合器实现。
testRectangleArea 测试方法接收一个 Rectangle 对象作为参数，并对其进行验证。

通过这种方式，您可以轻松地将多个参数组合成一个更复杂的对象，从而简化测试逻辑并提高代码的可读性。

# e. 自定义显示名称

默认情况下，JUnit 5 会根据提供的参数生成测试名称。但是，您也可以自定义显示名称。

示例：

@DisplayName("Display name of container")
@ParameterizedTest(name = "{index} ==> the rank of ''{0}'' is {1}")
@CsvSource({ "apple, 1", "banana, 2", "'lemon, lime', 3" })
void testWithCustomDisplayNames(String fruit, int rank) {
}

JUnit 5 提供了丰富的占位符选项，允许您在自定义测试显示名称中插入动态内容。这些占位符可以显著提高测试报告的可读性和信息量。以下是支持的占位符及其描述：

占位符	描述
`{displayName}`	方法的显示名称（即通过 `@DisplayName` 注解指定的名称）。
`{index}`	当前调用索引，从 1 开始计数。这有助于区分同一测试方法的不同执行实例。
`{arguments}`	完整的、以逗号分隔的参数列表。适用于快速查看传递给测试的所有参数值。
`{argumentsWithNames}`	完整的、以逗号分隔的参数列表，并包含每个参数的名称。这对于理解参数的意义特别有帮助。
`{argumentSetName}`	参数集的名称（如果提供了命名参数集）。
`{argumentSetNameOrArgumentsWithNames}`	根据参数的提供方式自动选择：如果有命名参数集，则使用 `{argumentSetName}`；否则使用 `{argumentsWithNames}`。
`{0}`, `{1}`, ...	按照索引引用单个参数值。这对于强调特定参数或简化复杂参数列表非常有用。

# 2. 假设

在单元测试中，假设（Assumptions）是一种特殊的条件判断，用于决定测试是否应该继续执行。与断言不同的是，假设失败并不会导致测试失败，而是会使测试跳过。这在某些情况下非常有用，例如：

当测试环境不具备某些条件时，可以跳过那些依赖于这些条件的测试。
当测试数据不可用时，可以选择跳过相关测试，而不是让它们失败。

# a. JUnit 5 中的假设

JUnit 5 提供了 Assumptions 类，其中包含了一些静态方法来实现假设。以下是一些常用的假设方法：

assumeTrue(boolean condition)：如果条件为 true，则继续执行测试；否则，跳过测试。
assumeFalse(boolean condition)：如果条件为 false，则继续执行测试；否则，跳过测试。
assumingThat(boolean condition, Executable executable)：如果条件为 true，则执行给定的代码块；否则，跳过该代码块。

# b. 示例代码

下面是一个使用假设的示例代码，展示了如何在 JUnit 5 中使用 Assumptions：

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.Assumptions;

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

class AssumptionExample {

    @Test
    void testWithAssumption() {
        // 假设操作系统是 Windows
        Assumptions.assumeTrue(System.getProperty("os.name").startsWith("Windows"));

        // 如果假设成立，继续执行测试
        assertEquals(4, 2 + 2, "2 + 2 should equal 4");
    }

    @Test
    void testWithAssumingThat() {
        // 假设某个环境变量存在
        Assumptions.assumingThat(
            System.getenv("TEST_ENV_VAR") != null,
            () -> {
                // 如果环境变量存在，执行测试
                assertEquals("expectedValue", System.getenv("TEST_ENV_VAR"), "Environment variable should have the expected value");
            }
        );
    }

    @Test
    void testWithAssumeFalse() {
        // 假设某个条件为 false
        Assumptions.assumeFalse(System.currentTimeMillis() % 2 == 0);

        // 如果假设成立，继续执行测试
        assertEquals(6, 3 + 3, "3 + 3 should equal 6");
    }
}

# c. 假设的使用场景

环境依赖：当测试需要特定的操作系统、数据库或其他外部服务时，可以使用假设来检查这些条件是否满足。
数据可用性：如果测试依赖于某些外部数据源，可以使用假设来检查数据是否可用。
性能测试：在性能测试中，可以使用假设来检查当前环境是否适合进行性能测试。
版本兼容性：在测试不同版本的库或框架时，可以使用假设来跳过不适用的测试。

通过合理使用假设，可以确保测试在不满足某些条件时不会失败，而是被跳过，从而提高测试的可靠性和灵活性。

# 3. 标记和过滤

在单元测试中，标记（Tags）和过滤（Filtering）是非常有用的工具，可以帮助开发者更灵活地管理和执行测试。通过标记，可以将测试用例归类，而过滤则允许根据这些标记选择性地运行测试。

# a. 标记（Tags）

JUnit 5 引入了 @Tag 注解，用于标记测试类或测试方法。标记可以用于分类测试，例如按功能、按重要性或按测试类型（单元测试、集成测试等）进行分类。标记的主要用途是在运行测试时进行筛选。

# 常见用法

标记测试方法：在测试方法上使用 @Tag 注解。
标记测试类：在测试类上使用 @Tag 注解，这样类中的所有测试方法都会继承该标记。

#示例代码

import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;

class TaggedTests {

    @Test
    @Tag("fast")
    void fastTest() {
        // 快速测试
    }

    @Test
    @Tag("slow")
    void slowTest() {
        // 慢速测试
    }

    @Test
    @Tag("integration")
    void integrationTest() {
        // 集成测试
    }

    @Test
    @Tag("unit")
    void unitTest() {
        // 单元测试
    }
}

# b. 过滤（Filtering）

通过标记，可以使用命令行工具或构建工具（如 Maven、Gradle）来过滤和运行特定的测试。以下是一些常见的过滤方法：

# 1. 使用 Maven 运行特定标记的测试

在 Maven 的 pom.xml 文件中，可以配置 maven-surefire-plugin 插件来运行特定标记的测试。

示例配置

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.0.0-M5</version>
            <configuration>
                <includes>
                    <include>**/*Test.java</include>
                </includes>
                <groups>fast,unit</groups>
            </configuration>
        </plugin>
    </plugins>
</build>

在这个配置中，<groups> 元素指定了要运行的标记，例如 fast 和 unit。

# 2. 使用 Gradle 运行特定标记的测试

在 Gradle 的 build.gradle 文件中，可以配置 test 任务来运行特定标记的测试。

示例配置

test {
    useJUnitPlatform {
        includeEngines 'junit-jupiter'
        includeTags 'fast', 'unit'
    }
}

在这个配置中，includeTags 方法指定了要运行的标记，例如 fast 和 unit。

# 3. 使用命令行运行特定标记的测试

在命令行中，可以使用 --select-tag 选项来运行特定标记的测试。

示例命令

mvn test -Dgroups=fast,unit

或者

gradle test --tests *TaggedTests --tags fast --tags unit

# c. 标记和过滤的使用场景

持续集成：在 CI/CD 管道中，可以根据标记选择性地运行测试，例如在快速构建阶段运行快速测试，而在夜间构建阶段运行所有测试。
本地开发：在本地开发环境中，可以根据需要运行特定类型的测试，例如只运行单元测试或集成测试。
测试分类：通过标记，可以将测试用例分类，便于管理和维护。
性能测试：在性能测试中，可以使用标记来区分不同类型的性能测试，例如 CPU 密集型测试和 I/O 密集型测试。

通过合理使用标记和过滤，可以提高测试的灵活性和效率，确保在不同的开发和部署环境中都能有效地运行测试。

# 4. 条件测试执行

在单元测试中，有时需要根据特定的条件来决定是否执行某个测试用例。JUnit 5 提供了 @EnabledIf 和 @DisabledIf 注解，以及一系列预定义的条件注解，可以方便地实现这一需求。以下是几种常见的条件测试执行方式：

# a. 操作系统和架构条件

可以使用 @EnabledOnOs 和 @DisabledOnOs 注解来根据操作系统和架构条件决定是否执行测试。

示例代码

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.condition.EnabledOnOs;
import org.junit.jupiter.api.condition.OS;

class OsConditionTests {

    @Test
    @EnabledOnOs(OS.WINDOWS)
    void testOnWindows() {
        // 只在 Windows 上运行
    }

    @Test
    @EnabledOnOs({OS.LINUX, OS.MAC})
    void testOnLinuxOrMac() {
        // 只在 Linux 或 Mac 上运行
    }

    @Test
    @DisabledOnOs(OS.WINDOWS)
    void testNotOnWindows() {
        // 不在 Windows 上运行
    }
}

# b. Java 运行环境条件

可以使用 @EnabledForJreRange 和 @DisabledForJreRange 注解来根据 Java 运行环境版本决定是否执行测试。

示例代码

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.condition.EnabledForJreRange;
import org.junit.jupiter.api.condition.JRE;

class JreConditionTests {

    @Test
    @EnabledForJreRange(min = JRE.JAVA_11)
    void testJava11OrHigher() {
        // 只在 Java 11 或更高版本上运行
    }

    @Test
    @DisabledForJreRange(max = JRE.JAVA_8)
    void testNotJava8OrLower() {
        // 不在 Java 8 或更低版本上运行
    }
}

# c. 原生图像条件

可以使用 @EnabledInNativeImage 和 @DisabledInNativeImage 注解在GraalVM原生镜像中启用或禁用容器或测试。

示例代码

@Test
@EnabledInNativeImage
void onlyWithinNativeImage() {
    // ...
}

@Test
@DisabledInNativeImage
void neverWithinNativeImage() {
    // ...
}

# d. 系统属性条件

可以使用 @EnabledIfSystemProperty 和 @DisabledIfSystemProperty 注解来根据系统属性决定是否执行测试。

示例代码

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.condition.EnabledIfSystemProperty;
import org.junit.jupiter.api.condition.DisabledIfSystemProperty;

class SystemPropertyConditionTests {

    @Test
    @EnabledIfSystemProperty(named = "os.name", matches = "Windows.*")
    void testOnWindowsByProperty() {
        // 只在 os.name 匹配 Windows.* 时运行
    }

    @Test
    @DisabledIfSystemProperty(named = "os.name", matches = "Linux")
    void testNotOnLinuxByProperty() {
        // 不在 os.name 匹配 Linux 时运行
    }
}

# d. 环境变量条件

可以使用 @EnabledIfEnvironmentVariable 和 @DisabledIfEnvironmentVariable 注解来根据环境变量决定是否执行测试。

示例代码

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.condition.EnabledIfEnvironmentVariable;
import org.junit.jupiter.api.condition.DisabledIfEnvironmentVariable;

class EnvironmentVariableConditionTests {

    @Test
    @EnabledIfEnvironmentVariable(named = "CI", matches = "true")
    void testInCiEnvironment() {
        // 只在 CI 环境变量为 true 时运行
    }

    @Test
    @DisabledIfEnvironmentVariable(named = "CI", matches = "false")
    void testNotInCiEnvironment() {
        // 不在 CI 环境变量为 false 时运行
    }
}

# f. 自定义条件

可以创建自定义的条件类来实现更复杂的逻辑。自定义条件类需要实现 ExecutionCondition 接口，并在注解中引用该类。

示例代码

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.condition.EnabledIf;
import org.junit.platform.commons.support.AnnotationSupport;
import org.junit.platform.commons.util.Preconditions;
import org.junit.platform.engine.support.hierarchical.SessionPerTestExecutionListener;
import org.junit.platform.engine.support.hierarchical.ThrowableCollector;
import org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder;
import org.junit.platform.testkit.engine.EngineTestKit;
import org.opentest4j.TestAbortedException;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.util.Optional;

public class CustomConditionTests {

    @Retention(RetentionPolicy.RUNTIME)
    @Target({ElementType.TYPE, ElementType.METHOD})
    @EnabledIf(condition = MyCustomCondition.class)
    public @interface EnabledIfMyCustomCondition {
        String value();
    }

    public static class MyCustomCondition implements ExecutionCondition {

        @Override
        public ConditionEvaluationResult evaluateExecutionCondition(ExtensionContext context) {
            Optional<EnabledIfMyCustomCondition> annotation = AnnotationSupport.findAnnotation(context.getElement(), EnabledIfMyCustomCondition.class);
            if (annotation.isPresent()) {
                String value = annotation.get().value();
                boolean conditionMet = checkCustomCondition(value);
                return conditionMet ? ConditionEvaluationResult.enabled("Custom condition met") : ConditionEvaluationResult.disabled("Custom condition not met");
            }
            return ConditionEvaluationResult.disabled("No custom condition annotation found");
        }

        private boolean checkCustomCondition(String value) {
            // 实现自定义逻辑
            return value.equals("true");
        }
    }

    @Test
    @EnabledIfMyCustomCondition("true")
    void testWithCustomCondition() {
        // 只在自定义条件满足时运行
    }
}

通过以上几种方式，可以灵活地控制测试用例的执行条件，从而更好地适应不同的测试环境和需求。

# 5. 测试实例生命周期

在单元测试中，测试实例的生命周期管理是一个重要的概念。JUnit 5 提供了多种机制来控制测试实例的创建和销毁，以确保测试的可靠性和性能。了解测试实例的生命周期有助于优化测试代码，避免不必要的资源浪费。

# a. 默认生命周期

默认情况下，JUnit 5 为每个测试方法创建一个新的测试实例。这意味着每个测试方法都在一个全新的实例上运行，不会受到其他测试方法的影响。这种方式的优点是测试之间完全隔离，但可能会导致资源开销较大。

示例代码

import org.junit.jupiter.api.Test;

class DefaultLifecycleTests {

    @Test
    void test1() {
        // 测试方法 1
    }

    @Test
    void test2() {
        // 测试方法 2
    }
}

# b. 每个测试类一个实例

如果希望在整个测试类中共享同一个测试实例，可以使用 @TestInstance(Lifecycle.PER_CLASS) 注解。这种方式可以减少对象创建的开销，适用于那些需要共享状态的测试。

示例代码

import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInstance;
import org.junit.jupiter.api.TestInstance.Lifecycle;

@TestInstance(Lifecycle.PER_CLASS)
class PerClassLifecycleTests {

    @BeforeAll
    void setup() {
        // 在所有测试方法之前执行一次
    }

    @Test
    void test1() {
        // 测试方法 1
    }

    @Test
    void test2() {
        // 测试方法 2
    }
}

# c. 生命周期管理的最佳实践

资源共享：如果多个测试方法需要共享相同的资源（如数据库连接、网络连接等），可以考虑使用 @TestInstance(Lifecycle.PER_CLASS) 来减少资源的重复创建。
状态隔离：如果测试方法之间需要完全隔离的状态，应使用默认的 @TestInstance(Lifecycle.PER_METHOD)。
初始化和清理：使用 @BeforeAll 和 @AfterAll 注解来管理测试类的初始化和清理工作，这些注解只能在 @TestInstance(Lifecycle.PER_CLASS) 模式下使用。
性能优化：对于资源密集型的测试，可以考虑使用 @TestInstance(Lifecycle.PER_CLASS) 来减少对象创建的开销，提高测试性能。

# 6. 测试执行顺序

在单元测试中，默认情况下，测试方法的执行顺序是不确定的。JUnit 5 提供了一些机制来控制测试方法的执行顺序，这对于某些依赖于特定顺序的测试场景非常有用。以下是几种常见的控制测试执行顺序的方法：

# a. 默认执行顺序

默认情况下，JUnit 5 不保证测试方法的执行顺序。这意味着测试方法可以按照任意顺序执行。这种设计是为了确保每个测试方法都是独立的，不依赖于其他测试方法的结果。

# b. 按名称排序

如果需要按方法名称的字典顺序执行测试方法，可以使用 @TestMethodOrder(MethodOrderer.Alphanumeric.class) 注解。

示例代码

import org.junit.jupiter.api.MethodOrderer;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestMethodOrder;

@TestMethodOrder(MethodOrderer.Alphanumeric.class)
class AlphanumericOrderTests {

    @Test
    void test1() {
        // 测试方法 1
    }

    @Test
    void test2() {
        // 测试方法 2
    }

    @Test
    void test3() {
        // 测试方法 3
    }
}

# c. 按自定义顺序

如果需要按自定义顺序执行测试方法，可以使用 @TestMethodOrder(MethodOrderer.OrderAnnotation.class) 注解，并在每个测试方法上使用 @Order 注解指定顺序。

示例代码

import org.junit.jupiter.api.MethodOrderer;
import org.junit.jupiter.api.Order;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestMethodOrder;

@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
class CustomOrderTests {

    @Test
    @Order(1)
    void test1() {
        // 测试方法 1
    }

    @Test
    @Order(3)
    void test3() {
        // 测试方法 3
    }

    @Test
    @Order(2)
    void test2() {
        // 测试方法 2
    }
}

# d. 按随机顺序

如果需要按随机顺序执行测试方法，可以使用 @TestMethodOrder(MethodOrderer.Random.class) 注解。

示例代码

import org.junit.jupiter.api.MethodOrderer;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestMethodOrder;

@TestMethodOrder(MethodOrderer.Random.class)
class RandomOrderTests {

    @Test
    void test1() {
        // 测试方法 1
    }

    @Test
    void test2() {
        // 测试方法 2
    }

    @Test
    void test3() {
        // 测试方法 3
    }
}

# 7. 嵌套测试

嵌套测试是 JUnit 5 中的一项强大功能，允许在一个测试类中定义多个嵌套的测试类。这有助于组织和管理复杂的测试场景，使测试代码更加清晰和模块化。嵌套测试类可以共享相同的数据设置和清理逻辑，从而减少重复代码。

# a. 嵌套测试的基本结构

嵌套测试的基本结构是在一个顶级测试类中定义多个静态内部类，每个内部类代表一个测试组。每个测试组可以有自己的 @BeforeEach 和 @AfterEach 方法，用于设置和清理测试环境。

示例代码

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;

class NestedTests {

    @BeforeEach
    void setUp() {
        // 顶级测试类的设置方法
    }

    @Nested
    class Group1 {

        @BeforeEach
        void setUpGroup1() {
            // 组 1 的设置方法
        }

        @Test
        void test1() {
            // 组 1 的测试方法 1
        }

        @Test
        void test2() {
            // 组 1 的测试方法 2
        }
    }

    @Nested
    class Group2 {

        @BeforeEach
        void setUpGroup2() {
            // 组 2 的设置方法
        }

        @Test
        void test1() {
            // 组 2 的测试方法 1
        }

        @Test
        void test2() {
            // 组 2 的测试方法 2
        }
    }
}

# b. 共享数据设置和清理

嵌套测试类可以共享顶级测试类中的数据设置和清理逻辑，同时也可以有自己独立的设置和清理逻辑。

示例代码

import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;

class NestedTests {

    private static DatabaseConnection dbConnection;

    @BeforeAll
    static void setUpAll() {
        dbConnection = new DatabaseConnection();
        // 初始化数据库连接
    }

    @BeforeEach
    void setUp() {
        // 顶级测试类的设置方法
    }

    @Nested
    class Group1 {

        @BeforeEach
        void setUpGroup1() {
            // 组 1 的设置方法
        }

        @Test
        void test1() {
            // 组 1 的测试方法 1
        }

        @Test
        void test2() {
            // 组 1 的测试方法 2
        }
    }

    @Nested
    class Group2 {

        @BeforeEach
        void setUpGroup2() {
            // 组 2 的设置方法
        }

        @Test
        void test1() {
            // 组 2 的测试方法 1
        }

        @Test
        void test2() {
            // 组 2 的测试方法 2
        }
    }
}

# c. 嵌套测试的优势

代码组织：嵌套测试类可以将相关的测试方法组织在一起，使测试代码更加清晰和易于维护。
资源共享：嵌套测试类可以共享顶级测试类中的资源，减少重复代码。
独立性：每个嵌套测试类可以有自己的设置和清理逻辑，确保测试之间的独立性。
可读性：嵌套测试类的结构有助于提高测试代码的可读性，使其他开发者更容易理解测试逻辑。

# 8. 构造函数和方法的依赖注入

在单元测试中，依赖注入是一种常见的技术，用于将外部依赖项传递给被测试的类或方法。然而，根据你的描述，这一节似乎更侧重于 JUnit 5 中的 ParameterResolver API，它允许在运行时动态解析测试方法的参数。

# a. 内置 ParameterResolver

JUnit 5 提供了几个内置的 ParameterResolver，这些解析器会自动注册并用于解析特定类型的参数。

TestInfoParameterResolver

用于解析 TestInfo 类型的参数，提供有关当前测试的信息。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInfo;

public class TestInfoExample {

    @Test
    void testWithTestInfo(TestInfo testInfo) {
        System.out.println("Running test: " + testInfo.getDisplayName());
    }
}

TestReporterParameterResolver

用于解析 TestReporter 类型的参数，允许在测试中记录消息。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestReporter;

public class TestReporterExample {

    @Test
    void testWithTestReporter(TestReporter testReporter) {
        testReporter.publishEntry("key", "value");
    }
}

RepetitionInfoParameterResolver

用于解析 RepetitionInfo 类型的参数，在重复测试中提供当前重复的信息。

import org.junit.jupiter.api.RepeatedTest;
import org.junit.jupiter.api.RepetitionInfo;

public class RepetitionInfoExample {

    @RepeatedTest(3)
    void testWithRepetitionInfo(RepetitionInfo repetitionInfo) {
        System.out.println("Current repetition: " + repetitionInfo.getCurrentRepetition());
    }
}

# b. 自定义 ParameterResolver

除了内置的 ParameterResolver，还可以自定义 ParameterResolver 来满足特定的需求。以下是一个简单的自定义 ParameterResolver 示例：

定义自定义 ParameterResolver

import org.junit.jupiter.api.extension.ExtensionContext;
import org.junit.jupiter.api.extension.ParameterContext;
import org.junit.jupiter.api.extension.ParameterResolutionException;
import org.junit.jupiter.api.extension.ParameterResolver;

public class CustomParameterResolver implements ParameterResolver {

    @Override
    public boolean supportsParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
        return parameterContext.getParameter().getType().equals(CustomDependency.class);
    }

    @Override
    public Object resolveParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
        return new CustomDependency();
    }
}

使用自定义 ParameterResolver

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;

@ExtendWith(CustomParameterResolver.class)
public class CustomParameterResolverExample {

    @Test
    void testWithCustomDependency(CustomDependency customDependency) {
        // 使用 customDependency 进行测试
    }
}

class CustomDependency {
    // 自定义依赖类
}

# 9. 测试接口和默认方法

JUnit Jupiter 允许在接口方法上声明@Test、@RepeatedTest、@ParameterizedTest、@TestFactory。

@TestInstance(Lifecycle.PER_CLASS)
interface TestLifecycleLogger {

    static final Logger logger = Logger.getLogger(TestLifecycleLogger.class.getName());

    @BeforeAll
    default void beforeAllTests() {
        logger.info("Before all tests");
    }

    @AfterAll
    default void afterAllTests() {
        logger.info("After all tests");
    }

    @BeforeEach
    default void beforeEachTest(TestInfo testInfo) {
        logger.info(() -> String.format("About to execute [%s]",
            testInfo.getDisplayName()));
    }

    @AfterEach
    default void afterEachTest(TestInfo testInfo) {
        logger.info(() -> String.format("Finished executing [%s]",
            testInfo.getDisplayName()));
    }

}

# 10. 重复测试

在单元测试中，有时需要多次运行同一个测试方法以确保其稳定性和可靠性。JUnit 5 提供了 @RepeatedTest 注解，允许开发者轻松地重复执行测试方法。以下是如何使用 @RepeatedTest 注解进行重复测试的详细指南。

# a. 基本用法

@RepeatedTest 注解用于标记一个测试方法，指示该方法应重复执行指定的次数。

示例代码

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

public class RepeatedTests {

    @RepeatedTest(5)
    void testRepeated(TestInfo testInfo) {
        int currentRepetition = testInfo.getRepetition();
        int totalRepetitions = testInfo.getTotalRepetitions();
        System.out.println("Repetition " + currentRepetition + " of " + totalRepetitions);
        assertTrue(currentRepetition <= totalRepetitions);
    }
}

在这个示例中，testRepeated 方法会被重复执行 5 次。每次执行时，TestInfo 参数提供了当前重复次数和总重复次数的信息。

# b. 使用 `RepetitionInfo` 参数

RepetitionInfo 是一个特殊的参数类型，可以在 @RepeatedTest 方法中使用，以获取当前重复的信息。

示例代码

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

public class RepeatedTests {

    @RepeatedTest(3)
    void testRepeatedWithRepetitionInfo(RepetitionInfo repetitionInfo) {
        int currentRepetition = repetitionInfo.getCurrentRepetition();
        int totalRepetitions = repetitionInfo.getTotalRepetitions();
        System.out.println("Repetition " + currentRepetition + " of " + totalRepetitions);
        assertTrue(currentRepetition <= totalRepetitions);
    }
}

在这个示例中，RepetitionInfo 参数提供了当前重复次数和总重复次数的信息，便于在测试方法中进行验证。

# 11. 动态测试

动态测试是 JUnit 5 引入的一种机制，允许在运行时动态地生成和执行测试用例。这种灵活性使得可以根据不同的条件或数据集生成多个测试用例，而无需在编译时定义所有测试方法。简单来说，它是一个测试用例的工厂。

# a. 基本概念

动态测试是通过 @TestFactory 注解的方法生成的。这些方法返回一个 DynamicNode 的流（如 Stream<DynamicTest> 或 Stream<DynamicContainer>），每个 DynamicNode 代表一个动态生成的测试用例或测试容器。

# b. 使用 `@TestFactory` 注解

@TestFactory 注解用于标记一个方法，该方法返回一个 DynamicNode 的流。每个 DynamicNode 可以是一个 DynamicTest 或 DynamicContainer。

示例代码

import org.junit.jupiter.api.DynamicTest;
import org.junit.jupiter.api.TestFactory;
import java.util.stream.Stream;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class DynamicTests {

    @TestFactory
    Stream<DynamicTest> generateDynamicTests() {
        return Stream.of(
            DynamicTest.dynamicTest("Test Case 1", () -> assertEquals(2, 1 + 1)),
            DynamicTest.dynamicTest("Test Case 2", () -> assertEquals(4, 2 * 2)),
            DynamicTest.dynamicTest("Test Case 3", () -> assertEquals(9, 3 * 3))
        );
    }
}

在这个示例中，generateDynamicTests 方法返回一个包含三个 DynamicTest 的流，每个 DynamicTest 都是一个独立的测试用例。

# c. 使用 `DynamicContainer`

DynamicContainer 允许将多个 DynamicTest 组织成一个容器，从而更好地组织和管理动态测试。

示例代码

import org.junit.jupiter.api.DynamicContainer;
import org.junit.jupiter.api.DynamicTest;
import org.junit.jupiter.api.TestFactory;
import java.util.stream.Stream;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class DynamicTests {

    @TestFactory
    Stream<DynamicNode> generateDynamicContainers() {
        return Stream.of(
            DynamicContainer.dynamicContainer("Math Tests",
                Stream.of(
                    DynamicTest.dynamicTest("Addition Test", () -> assertEquals(2, 1 + 1)),
                    DynamicTest.dynamicTest("Multiplication Test", () -> assertEquals(4, 2 * 2))
                )
            ),
            DynamicContainer.dynamicContainer("String Tests",
                Stream.of(
                    DynamicTest.dynamicTest("Length Test", () -> assertEquals(5, "Hello".length())),
                    DynamicTest.dynamicTest("Concatenation Test", () -> assertEquals("Hello World", "Hello" + " World"))
                )
            )
        );
    }
}

在这个示例中，generateDynamicContainers 方法返回两个 DynamicContainer，每个容器包含多个 DynamicTest，从而更好地组织和管理测试用例。

# 12. 超时(@Timeout注解)

@Timeout 注解用于指定测试方法的最大执行时间。如果测试方法在这个时间内没有完成，那么该测试将被视为失败。

作用：防止测试方法无限期地运行，从而影响整个测试套件的执行效率。
使用方法：将 @Timeout 注解添加到测试方法上，并指定超时时间（单位为毫秒）。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.Timeout;

public class TimeoutExampleTest {

    @Test
    @Timeout(1000) // 测试方法必须在1000毫秒内完成
    void testMethod() {
        // 测试逻辑
    }
}

注意事项：
- 如果测试方法在指定的时间内没有完成，JUnit 将抛出 TimeoutException。
- 可以在类级别使用 @Timeout 注解，这样所有测试方法都将共享相同的超时时间。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.Timeout;

@Timeout(1000) // 所有测试方法都必须在1000毫秒内完成
public class TimeoutClassExampleTest {

    @Test
    void testMethod1() {
        // 测试逻辑
    }

    @Test
    void testMethod2() {
        // 测试逻辑
    }
}

# 13. 并行执行

在 JUnit 5 中，可以通过配置并行执行来加速测试套件的运行。并行执行允许多个测试方法或测试类同时运行，从而减少总的测试时间。

作用：提高测试套件的执行效率，特别是在大型项目中，测试用例数量较多时效果显著。
配置方法：可以通过多种方式配置并行执行，包括在 junit-platform.properties 文件中设置，或者在代码中使用注解。

# 配置方法

通过 junit-platform.properties 文件配置

在项目的资源目录（通常是 src/test/resources）下创建或编辑 junit-platform.properties 文件，添加以下配置：
```
junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = concurrent
```

junit.jupiter.execution.parallel.enabled：启用并行执行。
junit.jupiter.execution.parallel.mode.default：设置默认的并行模式，可以是 concurrent 或 same-thread。

通过注解配置

可以在测试类或测试方法上使用 @Execution 注解来控制并行执行的行为。

import org.junit.jupiter.api.Execution;
import org.junit.jupiter.api.ExecutionMode;
import org.junit.jupiter.api.Test;

@Execution(ExecutionMode.CONCURRENT)
public class ParallelExecutionExampleTest {

    @Test
    void testMethod1() {
        // 测试逻辑
    }

    @Test
    void testMethod2() {
        // 测试逻辑
    }
}

@Execution(ExecutionMode.CONCURRENT)：指定测试方法或类在并行模式下执行。
@Execution(ExecutionMode.SAME_THREAD)：指定测试方法或类在同一线程中执行。

# 14. 内置扩展

JUnit 5 提供了一些内置的扩展，这些扩展可以帮助简化测试代码的编写和维护。以下是两个常用的内置扩展：

# a. @TempDir 扩展

@TempDir 注解用于创建一个临时目录，该目录在测试方法执行完毕后会被自动删除。这对于需要临时文件或目录的测试非常有用。

作用：自动创建和清理临时目录，避免手动管理临时文件。
使用方法：将 @TempDir 注解添加到 Path 类型的字段或参数上。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;
import java.nio.file.Path;

public class TempDirExampleTest {

    @TempDir
    Path tempDir;

    @Test
    void testWithTempDir() {
        // 使用 tempDir 进行测试
        System.out.println("临时目录路径: " + tempDir);
    }
}

# b. @AutoClose 扩展

@AutoClose 注解用于自动关闭实现了 AutoCloseable 接口的对象。这类似于 Java 的 try-with-resources 语句，可以确保在测试方法执行完毕后自动调用 close 方法。

作用：自动关闭资源，避免资源泄漏。
使用方法：将 @AutoClose 注解添加到 AutoCloseable 类型的字段或参数上。

class AutoCloseDemo {

    @AutoClose
    WebClient webClient = new WebClient();

    String serverUrl = // specify server URL ...

    @Test
    void getProductList() {
        // Use WebClient to connect to web server and verify response
        assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
    }

}

# 15. 模拟对象（Mock Objects）

模拟对象（Mock Objects）是一种在单元测试中使用的工具，用于模拟外部依赖项的行为，从而使测试更加隔离和可控。在 Java 中，最常用的模拟框架是 Mockito。

# a. Mockito库的介绍

Mockito 是一个流行的 Java 单元测试框架，用于创建和配置模拟对象。它提供了简单易用的 API，可以轻松地模拟方法调用、设置返回值、验证方法调用等。

优点：
- 简单易用，API 设计直观。
- 支持行为验证，可以验证方法是否被调用及其调用次数。
- 支持参数匹配，可以灵活地匹配方法参数。
- 支持 BDD（行为驱动开发）语义。

关于 Mockito 的更多信息，请参考 Mockito 教程 (opens new window)。

# b. 常用注解

@Mock：用于创建模拟对象。代理类中的所有方法，也可以直接使用Mockito.mock(...)
@Spy：用于创建部分模拟对象，即对象的真实方法会被调用，除非被明确模拟(stub)。
@InjectMocks：用于创建被测试对象，并自动注入其依赖的模拟对象。
@Captor：用于创建参数捕获器，可以在验证方法调用时捕获参数。

# c. 启用注解

要启用 Mockito 注解，需要在测试类上使用 @ExtendWith(MockitoExtension.class) 注解。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class MyServiceTest {

    @Mock
    private MyDependency dependency;

    @InjectMocks
    private MyService service;

    @Test
    void testMethod() {
        // 测试逻辑
    }
}

# d. 模拟方法

使用 when 方法来模拟对象的方法调用及其返回值。

import static org.mockito.Mockito.when;

@Test
void testMethod() {
    when(dependency.someMethod()).thenReturn("mocked value");

    String result = service.useDependency();

    assertEquals("mocked value", result);
}

# e. 参数匹配

使用参数匹配器来匹配方法参数。

import static org.mockito.ArgumentMatchers.anyString;

@Test
void testMethod() {
    when(dependency.someMethod(anyString())).thenReturn("mocked value");

    String result = service.useDependency("any string");

    assertEquals("mocked value", result);
}

# f. 行为验证

使用 verify 方法来验证方法是否被调用及其调用次数。

import static org.mockito.Mockito.verify;

@Test
void testMethod() {
    service.useDependency();

    verify(dependency).someMethod();
}

# g. BDD语义支持

BDD（行为驱动开发）是一种敏捷开发方法，通过自然语言（如Gherkin语法）描述系统行为，促进团队协作并确保开发围绕用户需求展开。它使用“Given-When-Then”格式编写用户故事，并将其转化为自动化测试用例，帮助团队在开发早期发现需求问题，确保代码符合预期行为。

Mockito 支持 BDD 语义，可以使用 BDDMockito 类来进行更自然的测试描述。

import static org.mockito.BDDMockito.given;
import static org.mockito.BDDMockito.then;

@Test
void testMethod() {
    given(dependency.someMethod()).willReturn("mocked value");

    String result = service.useDependency();

    then(dependency).should().someMethod();
    assertEquals("mocked value", result);
}

BDD也适用于集成测试，这方面推荐使用 Cucumber (opens new window)。

# 16. 测试套件

测试套件（Test Suite）是一种将多个测试类组合在一起的方式，以便一次性运行多个测试类。在 JUnit 5 中，可以使用 @Suite 注解来定义测试套件。

# a. 定义测试套件

要定义一个测试套件，需要创建一个新的测试类，并使用 @Suite 注解来指定包含的测试类。

import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectClasses({
    MyFirstTestClass.class,
    MySecondTestClass.class,
    MyThirdTestClass.class
})
public class MyTestSuite {
    // 这个类不需要任何方法
}

# b. 运行测试套件

定义好测试套件后，可以直接运行这个测试类，JUnit 会自动运行所有指定的测试类。

# c. 选择测试类的方式

@SelectClasses：指定具体的测试类。
@SelectPackages：指定包名，JUnit 会自动扫描该包下的所有测试类。
@SelectDirectories：指定目录，JUnit 会自动扫描该目录下的所有测试类。
@SelectFiles：指定文件，JUnit 会运行指定文件中的测试类。

# d. 示例

假设我们有两个测试类 MyFirstTestClass 和 MySecondTestClass，我们可以创建一个测试套件来运行这两个测试类。

// MyFirstTestClass.java
import org.junit.jupiter.api.Test;

public class MyFirstTestClass {

    @Test
    void testMethod1() {
        // 测试逻辑
    }

    @Test
    void testMethod2() {
        // 测试逻辑
    }
}

// MySecondTestClass.java
import org.junit.jupiter.api.Test;

public class MySecondTestClass {

    @Test
    void testMethod1() {
        // 测试逻辑
    }

    @Test
    void testMethod2() {
        // 测试逻辑
    }
}

// MyTestSuite.java
import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectClasses({
    MyFirstTestClass.class,
    MySecondTestClass.class
})
public class MyTestSuite {
    // 这个类不需要任何方法
}

# 17. 扩展模型

请参考：JUnit 5 测试扩展模型 (opens new window)。

# 五、持续集成中的单元测试

# 1. CI/CD流水线中集成单元测试

在 CI/CD（持续集成/持续交付）流水线中集成单元测试是确保代码质量的重要步骤。通过在每次代码提交后自动运行单元测试，可以及时发现和修复问题，提高软件的可靠性和稳定性。

作用：确保每次代码变更都不会引入新的错误，提高代码质量。
常见工具：Jenkins、GitHub Actions、GitLab CI、CircleCI 等。

# 2. 使用Maven或Gradle构建工具进行自动化测试

Maven 和 Gradle 是 Java 开发中最常用的构建工具，它们都提供了强大的支持来自动化单元测试的执行。

# Maven

配置文件：pom.xml
插件：maven-surefire-plugin 用于执行单元测试。

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0-SNAPSHOT</version>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.0.0-M5</version>
                <configuration>
                    <includes>
                        <include>**/*Test.java</include>
                    </includes>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <!-- 单元测试依赖 -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
            <version>5.7.0</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

# Gradle

配置文件：build.gradle
任务：test 任务用于执行单元测试。

plugins {
    id 'java'
    id 'application'
}

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.7.0'
}

test {
    useJUnitPlatform()
    testLogging {
        events "passed", "skipped", "failed"
    }
}

# 3. 测试报告的生成和分析

生成和分析测试报告可以帮助团队了解测试结果，识别潜在的问题，并优化测试策略。

# Maven

插件：maven-surefire-plugin 生成测试报告。
报告位置：默认生成在 target/surefire-reports 目录下。

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.0.0-M5</version>
    <configuration>
        <reportsDirectory>${project.build.directory}/surefire-reports</reportsDirectory>
        <reportFormats>plain,xml</reportFormats>
    </configuration>
</plugin>

# Gradle

任务：test 任务生成测试报告。
报告位置：默认生成在 build/reports/tests/test 目录下。

test {
    reports {
        html.enabled = true
        junitXml.enabled = true
    }
}

# 分析测试报告

HTML 报告：提供详细的测试结果，包括每个测试方法的执行时间和结果。
XML 报告：适合集成到 CI/CD 工具中，用于进一步分析和处理。
覆盖率报告：使用工具如 JaCoCo 生成代码覆盖率报告，帮助识别未覆盖的代码部分。

# JaCoCo 配置示例（Maven）

<build>
    <plugins>
        <plugin>
            <groupId>org.jacoco</groupId>
            <artifactId>jacoco-maven-plugin</artifactId>
            <version>0.8.7</version>
            <executions>
                <execution>
                    <goals>
                        <goal>prepare-agent</goal>
                    </goals>
                </execution>
                <execution>
                    <id>report</id>
                    <phase>prepare-package</phase>
                    <goals>
                        <goal>report</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

# JaCoCo 配置示例（Gradle）

apply plugin: 'java'
apply plugin: 'jacoco'

jacoco {
    toolVersion = "0.8.7"
}

test {
    finalizedBy jacocoTestReport
}

jacocoTestReport {
    reports {
        xml.enabled true
        html.enabled true
    }
}

# 六、最佳实践

# 1. 编写可维护的测试代码

编写可维护的测试代码是确保测试长期有效的重要因素。以下是一些最佳实践：

命名规范：测试方法的名称应清晰地描述测试的内容和预期结果。例如，testAdditionWithPositiveNumbers()。
简洁性：每个测试方法应尽可能简洁，只测试一个功能点。
隔离性：每个测试方法应独立运行，不受其他测试方法的影响。
数据准备：使用 @BeforeEach 和 @AfterEach 注解来准备和清理测试数据。
断言：使用明确的断言来验证测试结果，避免模糊的断言。
注释：适当添加注释，解释测试的目的和步骤。

# 2. 测试驱动开发（TDD）

测试驱动开发（Test-Driven Development, TDD）是一种软件开发方法，强调在编写实际代码之前先编写测试代码。TDD 的主要步骤包括：

编写测试：首先编写一个失败的测试用例。
运行测试：运行测试，确保它失败。
编写代码：编写最简单的代码使测试通过。
重构：在确保测试仍然通过的情况下，对代码进行重构以提高质量和可读性。
重复：重复上述步骤，逐步完善功能。

TDD 的好处包括：

早期发现问题：在开发过程中尽早发现和修复问题。
提高代码质量：确保代码具有良好的结构和可测试性。
文档：测试代码本身也是一种文档，帮助理解代码的功能。

# 3. 代码覆盖率的重要性

代码覆盖率是指测试代码执行了多少源代码的比例。高代码覆盖率意味着更多的代码路径得到了测试，从而提高了代码的可靠性。以下是一些关于代码覆盖率的最佳实践：

目标：通常建议代码覆盖率至少达到 70% 以上，但具体目标应根据项目需求而定。
工具：使用工具如 JaCoCo、Cobertura 等来生成代码覆盖率报告。
分析：定期分析代码覆盖率报告，找出未覆盖的代码部分并编写相应的测试。
平衡：追求高覆盖率的同时，也要确保测试的质量，避免为了提高覆盖率而编写无效的测试。

# 4. 平衡单元测试与其他测试类型

虽然单元测试是确保代码质量的基础，但仅靠单元测试是不够的。还需要结合其他类型的测试来全面验证系统的功能和性能。以下是一些建议：

单元测试：针对单个方法或类进行测试，确保基本功能的正确性。
集成测试：测试多个组件之间的交互，确保系统各部分协同工作。
系统测试：从整体上测试整个系统的功能和性能，确保满足业务需求。
性能测试：测试系统的性能指标，如响应时间、吞吐量等。
安全测试：测试系统的安全性，防止潜在的安全漏洞。

通过合理平衡不同类型的测试，可以更全面地确保系统的质量和可靠性。

# 七、总结

# 1. 单元测试对软件质量的影响

单元测试是软件开发过程中不可或缺的一部分，对提高软件质量有着重要的影响：

早期发现问题：单元测试可以在开发阶段早期发现代码中的错误和缺陷，减少后期调试和修复的成本。
提高代码质量：通过编写单元测试，开发者可以更好地理解代码的功能和边界条件，从而编写出更高质量的代码。
增强代码可维护性：单元测试提供了一种文档形式，帮助新加入的开发者快速理解代码的功能和结构。同时，测试代码的存在也使得代码的修改和重构更加安全。
提高团队信心：通过持续的单元测试，团队成员可以更有信心地进行代码变更和发布新版本，减少了因代码问题导致的生产环境故障。
促进持续集成：单元测试是持续集成（CI）流程中的重要环节，确保每次代码提交都能通过自动化的测试，从而保证代码的稳定性和可靠性。

# 2. 掌握单元测试技能的益处

掌握单元测试技能对个人和团队都有显著的好处：

提升个人技能：学习和掌握单元测试技能可以提高开发者的编程能力和测试思维，使开发者能够编写更健壮和可靠的代码。
提高工作效率：通过编写单元测试，开发者可以在开发过程中更快地定位和解决问题，减少调试时间，提高开发效率。
增强团队协作：单元测试可以作为团队成员之间的沟通工具，帮助团队成员更好地理解代码的功能和设计意图，减少误解和冲突。
降低维护成本：单元测试可以减少代码的维护成本，因为测试代码的存在使得代码的修改和重构更加安全，减少了因代码变更带来的风险。
提高客户满意度：高质量的软件产品可以提高客户的满意度和信任度，从而带来更多的业务机会和市场份额。

总之，单元测试不仅是提高软件质量的有效手段，也是提升个人和团队开发能力的重要工具。通过持续的实践和学习，可以更好地掌握单元测试技能，为软件项目的成功打下坚实的基础。

编辑

上次更新: 2025/01/17

← Java对象池技术 Spring体系介绍→

Java程序的单元测试

# 一、单元测试简介

# 1. 单元测试的概念

# 2. 单元测试的重要性

# 3. 单元测试的特点

# 二、Java单元测试框架

# 1. JUnit框架介绍

# a. JUnit的历史与发展

# b. JUnit的核心概念

# 2. TestNG框架概述

# a. TestNG的独特特性

# b. 与JUnit的比较

# 三、编写第一个JUnit测试案例

# 1. 设置开发环境（Maven）

# 2. 创建简单的Java类

# 3. 编写测试代码(Junit 5)

# a. 使用注解标记测试方法

# b. 断言（Assertions）的使用

# AssertJ库

# 四、高级单元测试技术

# 1. 参数化测试

# a. 使用参数

# b. 数据来源

# @ValueSource

# 无效源和空源

# @EnumSource

# 基本用法

# 指定模式（Modes）

# 使用 names 和 ignoreCase

# 结合其他数据源

# @MethodSource

# @FieldSource

# @CsvSource

# @CsvFileSource

# @ArgumentsSource

# 使用可重复注释的多个来源

# c. 参数转换

# 默认参数转换

# 自定义参数转换

# 使用 SimpleArgumentConverter

# 组合使用多个转换器

# d. 参数聚合

# ArgumentsAccessor

# 自定义聚合器

# e. 自定义显示名称

# 2. 假设

# a. JUnit 5 中的假设

# b. 示例代码

# c. 假设的使用场景

# 3. 标记和过滤

# a. 标记（Tags）

# 常见用法

# b. 过滤（Filtering）

# 1. 使用 Maven 运行特定标记的测试

# 2. 使用 Gradle 运行特定标记的测试

# 3. 使用命令行运行特定标记的测试

# c. 标记和过滤的使用场景

# 4. 条件测试执行

# a. 操作系统和架构条件

# b. Java 运行环境条件

# c. 原生图像条件

# d. 系统属性条件

# d. 环境变量条件

# f. 自定义条件

# 5. 测试实例生命周期

# a. 默认生命周期

# b. 每个测试类一个实例

# c. 生命周期管理的最佳实践

# 6. 测试执行顺序

# a. 默认执行顺序

# b. 按名称排序

# c. 按自定义顺序

# d. 按随机顺序

# 7. 嵌套测试

# a. 嵌套测试的基本结构

# b. 共享数据设置和清理

# c. 嵌套测试的优势

# 8. 构造函数和方法的依赖注入

# a. 内置 ParameterResolver

# b. 自定义 ParameterResolver

# 使用 `names` 和 `ignoreCase`

# 使用 `SimpleArgumentConverter`

# b. 使用 `RepetitionInfo` 参数

# b. 使用 `@TestFactory` 注解

# c. 使用 `DynamicContainer`