Java 软件测试（二）：Mockito与JUnit 5应用

单元测试在现代Java开发中扮演着越来越重要的角色。特别是在微服务架构盛行的今天，如何保证代码质量、实现快速反馈成为每个开发者必须面对的问题。

Mockito作为Java生态中最受欢迎的模拟框架，配合JUnit 5的强大测试能力，为我们提供了一套完整的单元测试解决方案。这两个工具的结合不仅能让测试代码更加简洁，还能有效隔离外部依赖，让测试更加可靠。

1. Mockito核心机制解析

Mockito的设计理念很简单：通过创建虚拟对象来替代真实的依赖，从而实现测试的隔离性。这种方式在处理数据库连接、网络请求或者复杂业务逻辑时特别有用。

1.1 Mock对象的本质

Mock对象本质上是一个代理，它可以模拟真实对象的行为但不执行实际逻辑。比如在测试用户服务时，我们不希望真的去调用数据库，这时候Mock对象就派上用场了。

它能够预设方法的返回值，记录方法的调用次数，甚至可以抛出指定的异常。这样我们就能专注于测试业务逻辑本身，而不用担心外部依赖的影响。

1.2 常用API详解

@Mock注解是最基础的，它告诉Mockito为某个字段创建一个模拟对象。使用起来很简单，只需要在字段上加上这个注解即可。

when()方法用来设置模拟对象的行为。比如when(userDao.findById(1)).thenReturn(user)就是告诉Mock对象，当调用findById(1)时返回指定的user对象。

verify()方法则用来验证模拟对象是否按预期被调用。这在测试方法调用逻辑时非常有用，可以确保某些关键方法确实被执行了。

1.3 高级功能应用

@Captor注解可以捕获方法调用时的参数，这在需要验证传入参数是否正确时很有帮助。特别是在处理复杂对象时，我们可以通过Captor来检查对象的具体内容。

ArgumentMatchers提供了丰富的参数匹配功能，比如any()、eq()、contains()等，让参数验证更加灵活。

2. JUnit 5新特性探索

JUnit 5相比之前的版本有了很大的改进，不仅在架构上更加模块化，在功能上也更加强大。

2.1 架构重构

JUnit 5采用了全新的架构设计，分为三个子项目：JUnit Platform、JUnit Jupiter和JUnit Vintage。Platform提供了测试引擎的基础设施，Jupiter是新的编程和扩展模型，Vintage则保证了向后兼容性。

这种设计让JUnit 5具备了更好的扩展性，开发者可以根据需要选择不同的测试引擎。

2.2 注解系统升级

新的注解系统更加直观易用。@BeforeEach和@AfterEach替代了之前的@Before和@After，语义更加清晰。

@DisplayName注解让测试方法的描述更加友好，特别是在生成测试报告时，可以显示更有意义的测试名称。

@ParameterizedTest支持参数化测试，可以用同一个测试方法测试多组数据，大大减少了重复代码。

2.3 条件测试与嵌套结构

条件测试功能让我们可以根据运行环境动态决定是否执行某些测试。比如@EnabledOnOs可以指定只在特定操作系统上运行测试。

@Nested注解支持嵌套测试类，这样可以更好地组织测试代码，让测试结构更加清晰。

3. 环境搭建与基础实践

3.1 依赖配置

首先需要在项目中添加必要的依赖。Maven项目可以在pom.xml中添加以下配置：

<dependencies>
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-core</artifactId>
        <version>4.6.1</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-engine</artifactId>
        <version>5.9.0</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-junit-jupiter</artifactId>
        <version>4.6.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>

3.2 基础测试示例

下面是一个简单的测试类示例，展示了Mockito和JUnit 5的基本用法：

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.InjectMocks;
import org.mockito.junit.jupiter.MockitoExtension;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void shouldReturnUserWhenValidId() {
        // 准备测试数据
        User expectedUser = new User(1L, "张三", "zhangsan@example.com");
        when(userRepository.findById(1L)).thenReturn(expectedUser);

        // 执行测试
        User actualUser = userService.getUserById(1L);

        // 验证结果
        assertEquals(expectedUser.getName(), actualUser.getName());
        verify(userRepository).findById(1L);
    }
}

这个例子展示了最基本的测试流程：准备数据、执行方法、验证结果。

4. 实际业务场景应用

4.1 电商订单处理测试

在电商系统中，订单处理通常涉及多个服务的协作。比如需要检查库存、处理支付、更新订单状态等。这种复杂的业务场景正是Mockito发挥作用的地方。

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock
    private InventoryService inventoryService;
    
    @Mock
    private PaymentService paymentService;
    
    @Mock
    private NotificationService notificationService;

    @InjectMocks
    private OrderService orderService;

    @Test
    void shouldProcessOrderSuccessfully() {
        // 模拟库存充足
        when(inventoryService.checkStock("ITEM001", 2)).thenReturn(true);
        // 模拟支付成功
        when(paymentService.processPayment(any(PaymentRequest.class)))
            .thenReturn(new PaymentResult(true, "PAY123"));

        OrderRequest request = new OrderRequest("ITEM001", 2, 100.0);
        OrderResult result = orderService.processOrder(request);

        assertTrue(result.isSuccess());
        verify(inventoryService).reserveStock("ITEM001", 2);
        verify(notificationService).sendOrderConfirmation(any());
    }

    @Test
    void shouldFailWhenInsufficientStock() {
        when(inventoryService.checkStock("ITEM001", 5)).thenReturn(false);

        OrderRequest request = new OrderRequest("ITEM001", 5, 250.0);
        OrderResult result = orderService.processOrder(request);

        assertFalse(result.isSuccess());
        assertEquals("库存不足", result.getErrorMessage());
        // 确保没有调用支付服务
        verifyNoInteractions(paymentService);
    }
}

4.2 异常处理测试

在实际开发中，异常处理是必不可少的。我们需要确保系统在遇到异常时能够正确处理。

@Test
void shouldHandlePaymentException() {
    when(inventoryService.checkStock(anyString(), anyInt())).thenReturn(true);
    when(paymentService.processPayment(any()))
        .thenThrow(new PaymentException("支付网关超时"));

    OrderRequest request = new OrderRequest("ITEM001", 1, 50.0);
    
    assertThrows(OrderProcessingException.class, () -> {
        orderService.processOrder(request);
    });

    // 验证库存被释放
    verify(inventoryService).releaseStock("ITEM001", 1);
}

4.3 参数捕获与验证

有时候我们需要验证传递给依赖服务的参数是否正确，这时候可以使用ArgumentCaptor：

@Test
void shouldSendCorrectNotification() {
    ArgumentCaptor<NotificationRequest> captor = 
        ArgumentCaptor.forClass(NotificationRequest.class);
    
    when(inventoryService.checkStock(anyString(), anyInt())).thenReturn(true);
    when(paymentService.processPayment(any()))
        .thenReturn(new PaymentResult(true, "PAY456"));

    OrderRequest request = new OrderRequest("ITEM002", 3, 150.0);
    orderService.processOrder(request);

    verify(notificationService).sendOrderConfirmation(captor.capture());
    
    NotificationRequest notification = captor.getValue();
    assertEquals("ITEM002", notification.getItemCode());
    assertEquals(3, notification.getQuantity());
}

5. 测试驱动开发实践

5.1 TDD基本流程

测试驱动开发遵循"红-绿-重构"的循环。先写一个失败的测试（红），然后写最少的代码让测试通过（绿），最后重构代码（重构）。

假设我们要开发一个计算器类，首先写测试：

@Test
void shouldAddTwoNumbers() {
    Calculator calculator = new Calculator();
    
    int result = calculator.add(3, 5);
    
    assertEquals(8, result);
}

这时候测试会失败，因为Calculator类还不存在。然后我们创建最简单的实现：

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

测试通过后，我们可以考虑是否需要重构。比如添加参数验证、支持更多数据类型等。

5.2 复杂业务的TDD

对于复杂的业务逻辑，TDD同样适用。比如开发一个用户注册功能：

@Test
void shouldRegisterUserSuccessfully() {
    // 模拟邮箱不存在的情况，返回false表示邮箱可用
    when(userRepository.existsByEmail("test@example.com")).thenReturn(false);
    // 模拟密码加密过程，返回加密后的密码
    when(passwordEncoder.encode("password123")).thenReturn("encoded_password");
    // 模拟用户保存操作，any(User.class)表示接受任何User类型的参数
    when(userRepository.save(any(User.class))).thenReturn(savedUser);

    // 创建注册请求对象，包含邮箱和密码
    RegisterRequest request = new RegisterRequest("test@example.com", "password123");
    // 调用用户服务的注册方法
    RegisterResult result = userService.register(request);

    // 断言注册结果为成功
    assertTrue(result.isSuccess());
    // 验证邮件服务的欢迎邮件发送方法被调用了一次
    verify(emailService).sendWelcomeEmail("test@example.com");
}

@Test
void shouldFailWhenEmailAlreadyExists() {
    // 模拟邮箱已存在的情况，返回true表示邮箱已被占用
    when(userRepository.existsByEmail("existing@example.com")).thenReturn(true);

    // 创建注册请求，使用已存在的邮箱
    RegisterRequest request = new RegisterRequest("existing@example.com", "password123");
    // 执行注册操作
    RegisterResult result = userService.register(request);

    // 断言注册失败
    assertFalse(result.isSuccess());
    // 验证错误消息内容是否正确
    assertEquals("邮箱已被注册", result.getErrorMessage());
}

6. 持续集成中的测试策略

6.1 CI环境配置

在持续集成环境中，单元测试是代码质量保证的第一道防线。我们需要确保每次代码提交都能触发完整的测试套件。

Maven项目可以通过以下命令运行测试：

mvn clean test

Gradle项目则使用：

./gradlew clean test

6.2 测试报告生成

现代CI工具都支持JUnit测试报告的解析和展示。可以在构建脚本中配置生成详细的测试报告：

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

6.3 测试覆盖率监控

使用JaCoCo等工具可以监控测试覆盖率，确保代码质量：

<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>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>

7. 总结

测试命名规范，好的测试名称应该清楚地表达测试的意图。推荐使用"should…When…"的格式，比如shouldReturnUserWhenValidIdProvided。

测试数据管理，测试数据应该独立且可预测。避免使用随机数据，尽量使用固定的测试数据集。可以考虑使用测试数据构建器模式来简化测试数据的创建。

Mock使用原则，不要过度使用Mock。只对那些难以构造、执行缓慢或者有副作用的依赖使用Mock。对于简单的值对象，直接创建真实对象往往更简单。

测试代码同样需要维护。当业务逻辑发生变化时，相应的测试也需要更新。保持测试代码的简洁和可读性，避免过于复杂的测试逻辑。