1. 项目概述为什么单元测试和Mock是Java开发的“安全带”干了这么多年Java开发我见过太多因为测试不到位而引发的“深夜救火”事件。一个看似简单的业务逻辑修改上线后却因为某个依赖服务不可用或数据状态异常导致整个功能瘫痪。事后复盘往往发现根源在于“测试覆盖不全”或“测试环境与生产环境差异巨大”。单元测试尤其是结合Mock技术的单元测试就是为这类问题量身定制的“安全带”和“安全气囊”。它不是为了应付KPI的代码行数而是让你在代码出海发布前能在自家港湾本地环境里模拟各种风浪异常情况确保核心逻辑坚不可摧。无论你是刚入行的新手还是被“Java八股文”困扰的面试者或是苦于提升代码质量的老手掌握这套组合拳都能让你写出更健壮、更易维护、面试时更有底气的代码。简单说它解决的是“如何在不依赖外部环境的情况下验证自己代码逻辑是否正确”的核心问题。2. 核心概念拆解单元测试与Mock到底是什么在深入实战之前我们必须把地基打牢。很多人对这两个概念的理解是模糊的甚至混为一谈这会导致在实际应用中走弯路。2.1 单元测试聚焦于“单元”的验证单元测试的“单元”通常指一个类中的一个方法它是软件中最小的可测试部件。其核心目标是隔离地验证这个“单元”的行为是否符合预期。关键特征快速执行速度应在毫秒级这样才能融入开发流程随时运行。独立测试用例之间不应有依赖顺序执行或单独执行结果必须一致。可重复在任何环境、任何时间运行只要代码不变结果就应该不变。自我验证测试结果必须是布尔值成功/失败无需人工干预判断。在Java生态中JUnit是事实上的标准单元测试框架。它提供了一套注解如Test,BeforeEach,AfterEach和断言方法如assertEquals,assertTrue来帮助我们组织和编写测试。注意单元测试不是集成测试。集成测试关注多个模块或系统间的交互而单元测试要求我们想尽办法将被测单元与它的“邻居”隔离开。这就是Mock技术登场的原因。2.2 Mock技术创造可控的“假邻居”当你的方法需要调用另一个类的方法、访问数据库、调用远程API或读取文件时这些外部依赖就成了单元测试的“绊脚石”。它们可能速度慢、不稳定、状态不可控或者根本不存在于测试环境中。Mock模拟技术就是为了解决这个问题而生。它允许你创建一个依赖对象的“替身”并预先设定这个替身的行为。比如你可以告诉Mock的“用户服务”“当getUserById(1)被调用时返回一个id为1、名为‘张三’的用户对象”而完全不需要真实的数据库或服务。Mock与Stub、Spy的区别面试常考点这是一个容易混淆的点理解它们能让你更精准地使用工具。Mock 关注行为验证。你不仅设定它的返回值更关心“某个方法是否被调用”、“以什么参数被调用”、“调用了几次”。例如验证emailService.send()是否被调用了一次。Stub桩 关注状态提供。你只关心它被调用时返回什么值或抛出什么异常不关心它是否被调用或调用次数。主要用于为测试提供必要的数据。Spy间谍 是部分真实对象的包装。默认情况下它会调用真实对象的方法但允许你对特定的方法进行拦截和验证Mock或打桩Stub。当你需要测试一个真实对象但又想监控或修改其部分行为时使用。在实际中Mockito这类框架模糊了这些概念的边界通常用mock()创建的对象既能当Stub用也能进行行为验证。但理解其本质有助于你在复杂场景下做出更合适的选择。3. 工具选型与环境搭建主流组合拳工欲善其事必先利其器。Java单元测试的生态已经非常成熟下面这套组合是经过无数项目验证的“黄金标准”。3.1 测试框架JUnit 5毫无疑问选择JUnit 5Jupiter。它相比JUnit 4有质的飞跃支持Lambda表达式、更丰富的扩展模型、动态测试等。它是现代Java项目的起点。Maven依赖dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version !-- 请使用最新稳定版 -- scopetest/scope /dependency3.2 Mock框架MockitoMockito是Java领域最流行、功能最强大的Mock框架没有之一。它API设计优雅学习曲线平缓能与JUnit 5无缝集成。Maven依赖dependency groupIdorg.mockito/groupId artifactIdmockito-core/artifactId version5.11.0/version !-- 请使用最新稳定版 -- scopetest/scope /dependency !-- 如果需要与JUnit 5更深度集成使用ExtendWith可以添加此依赖 -- dependency groupIdorg.mockito/groupId artifactIdmockito-junit-jupiter/artifactId version5.11.0/version scopetest/scope /dependency3.3 构建工具集成无论是Maven还是Gradle都内置了对测试的支持。执行mvn test或gradle test会自动运行src/test/java目录下所有符合命名规则的测试类。确保你的IDEIntelliJ IDEA或Eclipse已正确配置能够识别测试目录并运行测试。实操心得我强烈建议在IDE中为运行测试配置快捷键如CtrlShiftF10 in IDEA。边写代码边运行测试获得即时反馈这是测试驱动开发TDD的精髓也能极大提升开发效率和代码质量。4. 单元测试实战从编写到断言让我们从一个简单的业务场景开始。假设我们有一个PaymentService支付服务它依赖UserService用户服务来验证用户状态依赖BankService银行服务来执行扣款。4.1 被测代码示例// 业务代码 Service public class PaymentService { private final UserService userService; private final BankService bankService; public PaymentService(UserService userService, BankService bankService) { this.userService userService; this.bankService bankService; } /** * 执行支付 * param userId 用户ID * param amount 支付金额 * return 支付流水号 * throws IllegalArgumentException 用户不存在或状态异常 * throws RuntimeException 支付失败 */ public String pay(long userId, BigDecimal amount) { // 1. 验证用户 User user userService.getUserById(userId); if (user null || !user.isActive()) { throw new IllegalArgumentException(用户无效或未激活); } // 2. 执行扣款 String transactionId bankService.withdraw(user.getAccountId(), amount); if (transactionId null || transactionId.isEmpty()) { throw new RuntimeException(银行扣款失败); } // 3. 记录日志或执行其他操作... System.out.println(支付成功流水号: transactionId); return transactionId; } }4.2 编写基础单元测试无Mock首先我们看看如果不使用Mock测试会有多麻烦。你需要准备真实的UserService和BankService以及它们背后的数据库、网络连接。这几乎不可能在单元测试中完成。这也反向证明了Mock的必要性。4.3 使用Mockito创建Mock并打桩现在我们使用Mockito来隔离PaymentService。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; import java.math.BigDecimal; import static org.mockito.Mockito.*; import static org.junit.jupiter.api.Assertions.*; // 使用Mockito扩展自动初始化Mock和InjectMocks注解的字段 ExtendWith(MockitoExtension.class) class PaymentServiceTest { Mock private UserService mockUserService; // 创建UserService的Mock对象 Mock private BankService mockBankService; // 创建BankService的Mock对象 InjectMocks private PaymentService paymentService; // 创建PaymentService并将上面的Mock注入进去 Test void pay_Success() { // 1. 准备测试数据 long userId 1L; BigDecimal amount new BigDecimal(100.00); User mockUser new User(userId, 张三, account-123, true); String expectedTransactionId TX-2024-001; // 2. 定义Mock对象的行为打桩 - Stubbing // 当mockUserService的getUserById方法被传入参数1L时返回mockUser when(mockUserService.getUserById(1L)).thenReturn(mockUser); // 当mockBankService的withdraw方法被传入指定参数时返回预期的流水号 when(mockBankService.withdraw(account-123, amount)).thenReturn(expectedTransactionId); // 3. 执行被测方法 String actualTransactionId paymentService.pay(userId, amount); // 4. 验证结果断言 assertEquals(expectedTransactionId, actualTransactionId, 返回的流水号应该一致); // 5. 可选验证交互行为 // 验证getUserById被调用了一次且参数是1L verify(mockUserService, times(1)).getUserById(1L); // 验证withdraw被调用了一次且参数匹配 verify(mockBankService, times(1)).withdraw(account-123, amount); // 验证某个方法从未被调用 verify(mockUserService, never()).deleteUser(any()); } }代码解析与技巧ExtendWith(MockitoExtension.class) 这是JUnit 5的扩展机制它替代了旧版的RunWith负责处理Mockito注解的生命周期。Mock 标注一个字段Mockito会自动创建该类型的Mock对象。InjectMocks 标注待测试的类实例Mockito会尝试通过构造函数、setter或字段注入的方式将Mock字段注入到这个实例中。这极大简化了测试对象的组装。when(...).thenReturn(...) 这是最常用的打桩方法用于定义当Mock方法以特定参数被调用时的返回值。verify(...) 用于行为验证检查Mock对象的某个方法是否被调用、调用次数以及调用时的参数。这是Mock和Stub的关键区别体现。any() 是一个参数匹配器Argument Matcher表示“任何值”。类似的还有eq()等于、anyString()、anyLong()等。在验证verify或打桩when时使用匹配器可以更灵活。4.4 测试异常流与边界情况一个好的测试套件不仅要覆盖“阳光大道”更要覆盖“荆棘小路”。Test void pay_ShouldThrowException_WhenUserNotFound() { long userId 999L; BigDecimal amount new BigDecimal(50.00); // 打桩当查询不存在的用户时返回null when(mockUserService.getUserById(userId)).thenReturn(null); // 使用JUnit 5的assertThrows来验证是否抛出了预期的异常 IllegalArgumentException exception assertThrows( IllegalArgumentException.class, () - paymentService.pay(userId, amount) // 执行应抛出异常的方法 ); // 还可以进一步验证异常信息 assertTrue(exception.getMessage().contains(用户无效)); // 验证bankService的withdraw方法从未被调用因为前置条件失败 verify(mockBankService, never()).withdraw(anyString(), any()); } Test void pay_ShouldThrowException_WhenBankServiceFails() { long userId 1L; BigDecimal amount new BigDecimal(200.00); User activeUser new User(userId, 李四, account-456, true); when(mockUserService.getUserById(userId)).thenReturn(activeUser); // 打桩模拟银行服务返回空字符串表示失败 when(mockBankService.withdraw(anyString(), eq(amount))).thenReturn(); RuntimeException exception assertThrows( RuntimeException.class, () - paymentService.pay(userId, amount) ); assertTrue(exception.getMessage().contains(银行扣款失败)); }实操心得在测试异常时assertThrows方法比旧的Test(expected...)更强大因为它允许你获取到异常实例并对异常信息进行更细致的断言。同时记得验证在异常路径下后续的依赖方法如bankService.withdraw在用户无效时不应该被调用这能确保你的业务逻辑是严谨的。5. Mockito高级特性与实战技巧掌握了基础我们来看看Mockito那些能让你事半功倍的高级功能。5.1 参数匹配器Argument Matchers我们已经在上面用过any()和eq()。它们使得打桩和验证更加灵活。// 更灵活的验证只要withdraw的第一个参数以“account-”开头第二个参数是任意BigDecimal且被调用了一次 verify(mockBankService).withdraw(startsWith(account-), any(BigDecimal.class)); // 复杂的打桩根据不同的金额返回不同的结果 when(mockBankService.withdraw(anyString(), argThat(amt - amt.compareTo(new BigDecimal(1000)) 0))) .thenThrow(new RuntimeException(金额超限));argThat是最强大的匹配器允许你传入一个Lambda表达式进行自定义匹配。5.2 验证调用顺序与次数// 验证方法调用顺序 InOrder inOrder inOrder(mockUserService, mockBankService); inOrder.verify(mockUserService).getUserById(1L); inOrder.verify(mockBankService).withdraw(anyString(), any()); // 验证调用次数 verify(mockUserService, times(1)).getUserById(1L); // 精确一次 verify(mockUserService, atLeast(1)).getUserById(1L); // 至少一次 verify(mockUserService, atMost(3)).getUserById(1L); // 最多三次 verify(mockUserService, never()).getUserById(999L); // 从未被调用5.3 对void方法进行打桩与验证对于无返回值的方法需要使用doNothing()、doThrow()、doAnswer()等doXxx()系列方法。// 假设UserService有一个发送通知的void方法 public void sendNotification(User user, String message); // 测试中我们可以模拟它什么都不做或者抛出异常 doNothing().when(mockUserService).sendNotification(any(), eq(支付成功)); // 或者 doThrow(new RuntimeException(网络异常)).when(mockUserService).sendNotification(any(), anyString()); // 验证void方法被调用 verify(mockUserService).sendNotification(any(), contains(成功));5.4 使用Spy监控真实对象当你需要测试一个真实对象但只想模拟它的部分方法时Spy就派上用场了。// 假设我们有一个非常复杂的Calculator类我们想测试它的add方法但想模拟其内部的log方法 Calculator realCalculator new Calculator(); Calculator spyCalculator spy(realCalculator); // 创建真实对象的Spy // 让Spy的log方法什么都不做 doNothing().when(spyCalculator).log(anyString()); // 调用add方法它会真实执行但内部的log调用被我们拦截了 int result spyCalculator.add(2, 3); assertEquals(5, result); verify(spyCalculator).log(开始计算加法); // 依然可以验证log是否被调用重要提示 对Spy对象打桩时通常使用doReturn()、doThrow()、doNothing()系列方法而不是when(...).thenReturn(...)。因为后者会先调用真实方法可能产生副作用而前者不会。6. 测试代码的组织与最佳实践写出可维护的测试代码和写出可维护的业务代码同等重要。6.1 测试命名规范清晰的测试名是文档的一部分。推荐使用[方法名]_[测试场景]_[预期结果]的格式。pay_Successpay_ShouldThrowException_WhenUserNotFoundcalculateDiscount_ShouldReturnZero_WhenAmountIsNegative6.2 Given-When-Then模式这是一种结构化的测试编写模式让测试逻辑一目了然。Given给定 准备测试数据和Mock行为。对应测试中的// Arrange部分。When当 执行被测方法。对应// Act部分。Then那么 断言结果和验证行为。对应// Assert或// Verify部分。Test void pay_ShouldSucceed_WhenUserIsActiveAndHasSufficientBalance() { // Given long userId 1L; BigDecimal amount new BigDecimal(100.00); User activeUser new User(userId, 王五, acc-789, true); String expectedTxId TX-001; when(mockUserService.getUserById(userId)).thenReturn(activeUser); when(mockBankService.withdraw(activeUser.getAccountId(), amount)).thenReturn(expectedTxId); // When String actualTxId paymentService.pay(userId, amount); // Then assertEquals(expectedTxId, actualTxId); verify(mockBankService).withdraw(activeUser.getAccountId(), amount); }6.3 使用BeforeEach进行初始化如果多个测试方法需要相同的初始化步骤如创建一些公共的Mock对象或数据可以将其放在用BeforeEach注解的方法中。ExtendWith(MockitoExtension.class) class AdvancedPaymentServiceTest { Mock UserService userService; Mock BankService bankService; PaymentService paymentService; User defaultUser; BeforeEach void setUp() { // 在每个测试方法运行前执行 paymentService new PaymentService(userService, bankService); defaultUser new User(100L, 默认用户, default-acc, true); // 可以在这里为userService设置一些默认的、通用的打桩行为 // when(userService.getUserById(100L)).thenReturn(defaultUser); } // ... 测试方法 }注意事项 要小心在BeforeEach中设置过于具体或全局的打桩这可能会让测试用例变得不清晰或者导致测试间的意外耦合。通常建议只在BeforeEach中初始化对象具体的打桩行为放在每个测试方法内部。7. 常见问题排查与调试技巧即使经验丰富在编写测试时也会遇到各种“坑”。这里记录一些典型问题和解决方法。7.1 NullPointerException in Mockito这是最常见的问题。问题现象可能原因解决方案在测试方法中对Mock或InjectMocks字段直接操作时报NPE。未使用ExtendWith(MockitoExtension.class)或者使用了JUnit 4的RunWith。确保测试类上有ExtendWith(MockitoExtension.class)注解。InjectMocks的目标对象创建失败依赖注入为null。待测试类没有默认构造函数或者Mockito无法通过构造函数/Setter注入依赖。1. 检查PaymentService的构造函数。2. 可以尝试手动在BeforeEach中构造paymentService new PaymentService(userService, bankService);。Mock对象的方法被调用但未打桩返回了默认值如null。忘记为Mock对象的某个方法调用设置when(...).thenReturn(...)。检查测试逻辑确保所有被调用的Mock方法都有明确的打桩行为。对于返回集合的方法可以考虑返回空集合而非null。7.2 “Unnecessary Stubbing” 警告Mockito会检测到那些在测试中实际未被调用的打桩语句并抛出UnnecessaryStubbingException。这通常意味着你的测试逻辑有冗余或者测试路径未覆盖预期。处理方式审查测试这个打桩是否真的必要是不是你的测试用例设计有误使用MockitoSettings或Mockito.lenient()如果你确实需要一些“备用”但不一定被调用的打桩例如在BeforeEach中设置的通用桩可以标记其为宽松的。MockitoSettings(strictness Strictness.LENIENT) class MyTest { ... } // 或者对单个打桩设置 lenient().when(mockObject.someMethod()).thenReturn(...);但请谨慎使用这可能会掩盖真正的测试设计问题。7.3 验证失败Wanted but not invoked / Not wanted but invoked这直接指出了你的代码行为与预期不符。“Wanted but not invoked” 你预期某个方法会被调用但实际没有。检查你的业务逻辑是否因为条件判断、异常提前返回等原因跳过了这行代码。“Not wanted but invoked” 你预期某个方法不会被调用如verify(mock, never())但它却被调用了。这通常是边界条件或异常处理逻辑有漏洞的信号。调试技巧 在测试方法开始或验证前使用Mockito.mockingDetails(mockObject).printInvocations()打印出Mock对象所有被调用的记录这能帮你清晰地看到实际发生了什么。7.4 测试Spring Bean如Service, Component对于Spring Boot项目你可能会想测试一个注入了大量Spring Bean的类。这时不要用完整的Spring上下文启动来跑单元测试那会变成又慢又脆弱的集成测试。正确做法 依然使用Mockito。对于Spring管理的Bean你可以在测试类上使用SpringBootTest但设置webEnvironment WebEnvironment.NONE来避免启动Web容器并配合MockBean来Mock掉你不关心的Bean。这比完整启动快但依然比纯Mockito慢。推荐坚持纯单元测试不依赖SpringBootTest。你的Service如果通过构造函数注入依赖这是Spring推荐的方式那么单元测试就可以像我们前面演示的那样直接用new创建Service并用Mockito创建依赖的Mock。这才是最快、最纯粹的单元测试。// 方式2示例即使你的UserService上有Service注解也不影响单元测试 Service public class AnotherService { private final UserService userService; // 通过构造器注入 public AnotherService(UserService userService) { this.userService userService; } // ...业务方法 } // 单元测试 ExtendWith(MockitoExtension.class) class AnotherServiceTest { Mock UserService mockUserService; AnotherService anotherService; // 没有InjectMocks因为我们要手动控制 BeforeEach void setUp() { // 手动构造清晰明了 anotherService new AnotherService(mockUserService); } // ... 测试方法 }我个人在实际项目中95%的测试都是这种不启动Spring上下文的纯单元测试。只有涉及到需要测试Spring配置、事务管理或Web层集成时才会考虑使用SpringBootTest。记住单元测试的核心是速度和隔离。当你发现测试跑得很慢时第一个要怀疑的就是是否引入了不必要的重量级框架。