java 单元测试怎么写(Java单元测试编写指南)

Java 单元测试实战指南：从入门到精通

在软件工程中，单元测试（Unit Testing） 常被比喻为代码的“安全网”。它不仅能帮助开发者在早期发现 Bug，还能作为重构时的信心保障。然而，对于许多 Java 开发者而言，单元测试往往被视为一项枯燥、繁琐且“可有可无”的任务。 本文将围绕 “Java 单元测试怎么写” 这一核心问题，从基础工具选型、核心原则、实战技巧到最佳实践，为你提供一份全面且可落地的指南。

一、 为什么你需要单元测试？

在深入“怎么写”之前，先明确“为什么写”。高质量的单元测试应具备以下价值： 1. 快速反馈：修改代码后，瞬间知道是否破坏了原有逻辑。 2. 文档作用：测试用例本身就是最准确的 API 使用文档。 3. 促进解耦：为了便于测试，开发者往往会写出更模块化、低耦合的代码。 4. 减少回归 Bug：确保新功能不会导致旧功能失效。

二、 核心工具链：Java 单元测试的“三剑客”

在 Java 生态中，单元测试通常由以下三个核心组件构成：

组件	作用	主流选择
测试框架	提供测试生命周期管理、断言、异常捕获等基础设施	JUnit 5 (当前标准)
Mock 框架	模拟外部依赖（如数据库、第三方 API、其他服务）	Mockito (事实标准)
断言库	提供丰富的断言方法，使测试意图更清晰	AssertJ (推荐) 或 JUnit 内置

提示：如果你使用 Spring Boot，通常只需引入 `spring-boot-starter-test`，它会自动包含 JUnit 5、Mockito 和 AssertJ。

三、 单元测试的黄金法则：AAA 模式

无论测试逻辑多复杂，优秀的单元测试都遵循 AAA 模式（Arrange, Act, Assert），即准备、执行、断言。这种结构让测试代码易读、易维护。

1. Arrange（准备）

设置测试环境：初始化对象、配置 Mock 行为、准备测试数据。

2. Act（执行）

调用被测试的方法（SUT, System Under Test）。

3. Assert（断言）

验证执行结果是否符合预期：检查返回值、状态变化或 Mock 方法的调用次数。

四、 实战演练：从简单到复杂

场景 1：纯逻辑测试（无外部依赖）

假设我们有一个计算折扣的服务类： ```java public class DiscountService { public double calculateDiscount(double price, int quantity) { if (quantity > 10) { return price 0.9; // 9折 } return price; } } ``` 测试代码（JUnit 5 + AssertJ）： ```java import static org.assertj.core.api.Assertions.assertThat; import org.junit.jupiter.api.Test; class DiscountServiceTest { private final DiscountService service = new DiscountService(); @Test void testNormalPrice() { // Arrange double price = 100.0; int quantity = 5; // Act double result = service.calculateDiscount(price, quantity); // Assert assertThat(result).isEqualTo(100.0); } @Test void testBulkDiscount() { // Arrange double price = 100.0; int quantity = 11; // Act double result = service.calculateDiscount(price, quantity); // Assert assertThat(result).isEqualTo(90.0); } } ```

场景 2：带有依赖的测试（使用 Mockito）

假设 `OrderService` 依赖 `PaymentGateway` 进行支付： ```java public class OrderService { private final PaymentGateway paymentGateway; public OrderService(PaymentGateway paymentGateway) { this.paymentGateway = paymentGateway; } public boolean placeOrder(Order order) { boolean paymentSuccess = paymentGateway.pay(order.getAmount()); if (paymentSuccess) { order.setStatus("PAID"); return true; } return false; } } ``` 测试代码： ```java import static org.mockito.Mockito.; import static org.assertj.core.api.Assertions.assertThat; 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) // 启用 Mockito class OrderServiceTest { @Mock private PaymentGateway paymentGateway; // 模拟依赖 @InjectMocks private OrderService orderService; // 自动注入 Mock 依赖 @Test void testSuccessfulPayment() { // Arrange Order order = new Order(1L, 50.0); when(paymentGateway.pay(50.0)).thenReturn(true); // 配置 Mock 行为 // Act boolean result = orderService.placeOrder(order); // Assert assertThat(result).isTrue(); assertThat(order.getStatus()).isEqualTo("PAID"); verify(paymentGateway).pay(50.0); // 验证支付网关被调用了一次 } @Test void testFailedPayment() { // Arrange Order order = new Order(2L, 100.0); when(paymentGateway.pay(100.0)).thenReturn(false); // Act boolean result = orderService.placeOrder(order); // Assert assertThat(result).isFalse(); assertThat(order.getStatus()).isNotEqualTo("PAID"); } } ```

五、 常见陷阱与最佳实践

1. 测试什么？不测试什么？

• ✅ 要测试：业务逻辑、边界条件、异常处理。
• ❌ 不要测试：
• 框架代码（如 Spring 的依赖注入、JPA 的映射）。
• Getter/Setter（除非有额外逻辑）。
• 第三方库的 API 行为。
• UI 渲染细节（应使用集成测试或 E2E 测试）。

2. 测试命名规范

测试方法名应清晰描述测试场景，推荐格式：`testMethodName_Scenario_ExpectedResult`。

• 坏名字：`test1()`, `testDiscount()`
• 好名字：`testCalculateDiscount_WhenQuantityOver10_Returns90Percent()`

3. 独立性原则

• 每个测试用例必须独立运行，互不影响。
• 不要依赖其他测试的执行顺序。
• 每个测试完成后应清理状态（Mockito 默认在每个测试后重置 Mock 对象）。

4. 覆盖边界值

不要只测试“快乐路径”（Happy Path）。务必覆盖：

• 空值（null）
• 空集合
• 零值
• 极大/极小值
• 异常输入

5. 避免过度 Mock

Mock 是双刃剑。如果过度 Mock，测试可能通过，但集成时失败。

• 原则：只 Mock 外部依赖或复杂逻辑，尽量测试真实对象。
• 技巧：对于简单工具类，直接实例化测试而非 Mock。

六、 进阶：如何测试私有方法？

最佳实践：不要直接测试私有方法！ 私有方法是类的内部实现细节。如果私有方法难以测试，通常意味着类职责过重，应提取为独立的工具类或拆分服务类。 如果确实需要测试私有方法的复杂逻辑，可以考虑： 1. 重构：将私有方法提取为包私有（package-private）或独立类，便于测试。 2. 反射（不推荐，脆弱且慢）：通过 Java 反射访问私有方法。 3. 通过公共方法间接测试：设计测试用例，使得公共方法的输入能触发私有方法的逻辑分支。

七、 总结

写好 Java 单元测试并非一蹴而就，它需要： 1. 掌握工具：熟练使用 JUnit 5 和 Mockito。 2. 遵循模式：坚持 AAA 结构，保持测试清晰。 3. 注重质量：测试代码也是代码，需保持可读性和可维护性。 4. 持续实践：从简单的逻辑测试开始，逐步覆盖复杂场景。 单元测试不是负担，而是投资。当你建立起完善的测试体系后，你将获得更快的迭代速度、更稳定的代码质量和更强的重构信心。 行动建议：从今天开始，为你最近修改的一个核心业务类编写第一个单元测试。从小处着手，逐步扩展你的测试覆盖率。