【Mockito终极指南】：精通Mock测试的15个实用技巧和最佳实践

 # 摘要 本文系统地介绍了Mockito框架，这是Java领域中广泛使用的一款模拟对象库，主要应用于单元测试。首先，本文提供了Mockito的简介和测试原理，然后深入探讨了Mockito的核心概念和基础实践，包括创建和配置Mock对象、验证行为方法以及Stubbing技巧。接着，文章转向Mockito测试的进阶技巧，涵盖了参数匹配器的使用、验证复杂交互以及测试遗留代码的策略。此外，还讨论了Mockito的高级特性和最佳实践，包括使用BDD风格的API、与其他测试框架的集成，以及测试代码的可读性和维护。最后，通过多个实践案例分析，本文展示了Mockito在不同场景下的应用效果和经验分享。 # 关键字 Mockito；单元测试；Mock对象；参数匹配器；测试维护；代码集成 参考资源链接：[mockito-core-4.3.1中文-英文对照文档快速指南](https://wenku.csdn.net/doc/5q5rf7px4x?spm=1055.2635.3001.10343) # 1. Mockito简介及测试原理 ## 1.1 什么是Mockito？ Mockito是一个流行的Java Mocking框架，广泛用于单元测试。它允许开发者创建和配置Mock对象，并验证期望的行为，使得开发者能够专注于代码逻辑的测试而不是依赖细节。 ## 1.2 Mock与Stub的区别 在单元测试中，Mock和Stub都是用来模拟依赖对象的方法。不同的是，Mock对象可以验证交互，而Stub对象只能提供预设的响应。Mockito中的Mock对象可以模拟实际的方法调用，验证是否被以预期的方式调用。 ## 1.3 Mock测试的基本原理 Mock测试依赖于模拟外部或复杂的依赖项，以便隔离和验证代码片段。Mockito利用代理模式创建轻量级的测试替身，通过拦截对Mock对象的方法调用，并根据测试逻辑给出响应，从而进行测试。 ```java // 示例代码：创建Mock对象并验证其行为 Mockito.mock(SomeClass.class); verify(mockedObject).someMethod(anyInt()); ``` 以上章节详细介绍了Mockito的基本概念和测试原理，为后续深入使用Mockito做好了铺垫。通过理解Mock与Stub的区别，我们可以更好地选择适合的测试工具。而Mock测试的基本原理则为理解Mockito如何工作提供了基础。 # 2. Mockito核心概念和基础实践 ## 2.1 Mock对象的创建与配置 ### 2.1.1 理解Mock对象的作用与创建 Mock对象在软件开发中是一种用于代替真实对象进行测试的工具。在单元测试中，Mock对象可以模拟复杂对象的外部依赖，从而允许开发者专注于测试特定的逻辑。创建Mock对象主要目的是通过模拟外部依赖的交互来隔离测试单元，这样可以确保测试的独立性，并且当依赖不可用或不稳定时，测试仍可进行。 使用Mockito创建Mock对象非常简单。首先，需要引入Mockito库，并在测试类中使用Mockito的静态方法`mock()`来创建Mock对象。下面是一个创建Mock对象的基本示例： ```java import static org.mockito.Mockito.*; // 创建一个被Mock的类实例 SomeClass mockObject = mock(SomeClass.class); ``` 这里，`SomeClass`是我们想要模拟的类，`mock()`方法会返回一个`SomeClass`接口的Mock实例。创建Mock对象后，我们就可以配置它以响应特定的方法调用。 ### 2.1.2 配置Mock对象的行为 配置Mock对象行为是确保测试准确性的重要步骤。Mockito允许我们定义当Mock对象接收到特定方法调用时的行为。这包括返回特定的值、抛出异常、调用真实的实现或根据参数来定制行为等。 在Mockito中，我们可以使用`when()`方法来定义Mock对象的行为： ```java // 配置当调用mock对象的某个方法时返回一个特定的值 when(mockObject.someMethod()).thenReturn("expectedValue"); ``` 在上面的代码中，`someMethod()`方法被调用时，Mock对象将会返回字符串`"expectedValue"`。`when()`方法是Mockito中非常常用的配置方式之一，它允许你定义方法调用和期望返回值之间的关系。 除此之外，还可以使用`doThrow()`, `doAnswer()`, `doNothing()`, 和 `doReturn()`等方法来配置Mock对象对方法调用的不同响应，例如： ```java // 当调用mock对象的某个方法时抛出异常 doThrow(new RuntimeException("Exception message")).when(mockObject).someMethod(); // 当调用mock对象的某个方法时不做任何操作 doNothing().when(mockObject).someMethod(); ``` 配置Mock对象是一个需要根据测试需求细致考虑的过程。通过合理配置Mock对象，我们可以更精确地模拟出实际应用中的各种场景，从而使单元测试更加贴近真实环境，提高测试的可靠性和准确性。 ## 2.2 验证行为的方法 ### 2.2.1 验证方法调用次数和顺序 验证测试中的交互行为是确保软件系统按预期工作的重要一环。Mockito提供了强大的工具来验证Mock对象的方法调用次数、调用顺序和其他关键属性。 当使用Mockito进行测试时，我们往往需要检查特定方法是否被调用了正确的次数。为此，Mockito提供了`times()`方法。该方法可以与`verify()`方法结合使用，以确保特定方法调用的次数符合预期。 ```java // 验证方法被调用了特定的次数 verify(mockObject, times(1)).someMethod(); ``` 上面的代码检查`mockObject`的`someMethod()`方法是否被调用了一次。如果我们想检查方法是否从未被调用，可以使用`never()`方法： ```java // 验证方法从未被调用 verify(mockObject, never()).someMethod(); ``` 除了调用次数之外，有时还需要验证方法的调用顺序。Mockito允许我们通过设置期望的调用顺序来验证交互，具体通过`inOrder()`方法实现： ```java InOrder inOrder = inOrder(mockObject); // 检查方法调用的顺序 inOrder.verify(mockObject).firstMethod(); inOrder.verify(mockObject).secondMethod(); ``` 上述代码中`inOrder()`验证`mockObject`上`firstMethod()`方法是否在`secondMethod()`之前被调用。如果调用顺序不匹配，测试将会失败。 ### 2.2.2 验证方法调用的参数匹配 在单元测试中，验证方法是否以正确的参数被调用同样至关重要。Mockito提供了参数匹配器来实现这一点，它允许我们指定哪些参数值是可接受的。 考虑一个方法`someMethod(int value)`，我们可能想验证该方法是否以特定的参数值被调用： ```java // 验证方法被特定参数调用 verify(mockObject).someMethod(10); ``` 上述代码将会检查`mockObject`的`someMethod(int value)`是否以参数`10`被调用。如果调用确实发生了，测试将通过；否则，测试失败。 然而，常常我们只关心参数的特定属性，或者参数的匹配条件比较复杂，这时候可以使用Mockito的`argThat()`方法结合自定义的`ArgumentMatcher`。例如，如果我们关心的是参数值是否大于0，可以这样实现： ```java // 定义一个自定义参数匹配器 class GreaterThanZeroMatcher extends ArgumentMatcher<Integer> { @Override public boolean matches(Integer argument) { return argument > 0; } } // 使用自定义匹配器验证方法调用 verify(mockObject).someMethod(argThat(new GreaterThanZeroMatcher())); ``` 上述代码中`GreaterThanZeroMatcher`是一个自定义的参数匹配器，它检查传入的`Integer`参数是否大于0。通过`argThat()`方法与这个自定义匹配器结合，我们可以以非常灵活的方式检查方法调用的参数。 通过这些参数匹配技术，我们可以确保单元测试的精确性和可靠性，从而确保软件系统的行为符合我们的预期。 ## 2.3 Stubbing技巧 ### 2.3.1 基本的Stubbing使用场景 在测试中，"Stubbing"是指为Mock对象的方法调用提供一个预定的响应，通常是一个返回值或一个异常。通过这种模拟方法，我们可以控制测试中依赖对象的行为，从而使得测试可以专注于特定的单元。 在Mockito中，Stubbing的使用是通过`when().thenReturn()`结构来实现的。下面是创建一个简单的Stubbing场景： ```java // Stubbing一个方法以返回一个值 when(mockObject.someMethod()).thenReturn("expectedValue"); ``` 在这个例子中，当我们调用`mockObject.someMethod()`时，它会返回字符串`"expectedValue"`。这使得在测试中，无论外部依赖如何变化，我们都能得到一个稳定且可控的响应。 除了返回值，我们还可以用同样的结构返回一个异常： ```java // Stubbing一个方法以抛出异常 when(mockObject.someMethod()).thenThrow(new RuntimeException("Mocked exception")); ``` 这将使得每次调用`mockObject.someMethod()`都会抛出一个运行时异常。这对于测试错误处理路径非常有用。 ### 2.3.2 高级Stubbing技巧 高级Stubbing技巧使得我们可以根据方法的参数和调用历史来定制返回值。例如，我们可以根据传入的参数值返回不同的结果： ```java // 根据不同的参数值返回不同的结果 when(mockObject.someMethod(10)).thenReturn("valueFor10"); when(mockObject.someMethod(20)).thenReturn("valueFor20"); ``` 此外，我们还可以使用`doAnswer()`来实现更复杂的交互，例如在方法被调用时执行额外的逻辑： ```java // 使用doAnswer()实现当方法被调用时执行额外逻辑 doAnswer(invocation -> { // 在这里可以访问到方法的参数 int value = invocation.getArgument(0); // 执行额外的逻辑 System.out.println("Value passed: " + value); // 返回值可以根据需要计算得到 return "fromAnswer"; }).when(mockObject).someMethod(anyInt()); ``` 在这个例子中，`someMethod(int value)`的每次调用都会在控制台输出传入的参数值，并返回字符串`"fromAnswer"`。`doAnswer()`方法允许我们访问方法调用的参数，并在方法执行时添加任意逻辑。 另一个高级技巧是使用`doNothing()`和`doReturn().when()`来控制对void方法的调用： ```java // Stubbing void方法 doNothing().when(mockObject).voidMethod(); ``` 这个例子中，`voidMethod()`是一个不返回任何值的方法。使用`doNothing()`可以防止调用这个方法时抛出异常。 通过使用这些高级Stubbing技巧，我们可以创建更复杂和更精确的测试用例，确保软件的各个部分按照预期工作，无论外部环境如何变化。 # 3. Mockito测试进阶技巧 ## 3.1 参数匹配器的深入使用 ### 3.1.1 自定义参数匹配器 Mockito 允许用户定义自己的参数匹配器，以实现更灵活的测试场景。自定义参数匹配器不仅可以满足特定需求，还可以使测试更具有可读性。创建一个自定义参数匹配器涉及实现 `org.mockito.ArgumentMatcher` 接口。此接口只有一个方法 `matches` 需要实现，它返回一个布尔值以指示匹配是否成功。 ```java public class CustomMatcher extends ArgumentMatcher<SomeObject> { private final String expectedName; public CustomMatcher(String expectedName) { this.expectedName = expectedName; } @Override public boolean matches(Object argument) { return argument instanceof SomeObject && ((SomeObject) argument).getName().equals(expectedName); } } // 使用自定义匹配器 when(service.find(any(CustomMatcher.class))).thenReturn(existingObject); ``` 在上述代码中，我们定义了一个针对 `SomeObject` 类型的参数匹配器 `CustomMatcher`，它检查传入对象的 `name` 属性是否与期望的名称相符。然后我们使用这个匹配器作为 `find` 方法的参数。 ### 3.1.2 参数匹配器与Mockito验证 当参数匹配器被用于验证时，Mockito 会利用匹配器来检查预期调用是否发生。在参数匹配器的帮助下，可以创建更为复杂的验证条件，例如验证方法在一组特定条件下的调用次数。 ```java verify(service, times(1)).process(argThat(new CustomMatcher("expectedName"))); ``` 上述代码片段演示了如何使用自定义匹配器来验证 `process` 方法仅在 `SomeObject` 的 `name` 属性为 `"expectedName"` 的情况下被调用了一次。这种方式可以确保验证行为的灵活性和精确性。 ## 3.2 验证复杂交互 ### 3.2.1 验证对象间的交互 在复杂的系统中，对象间交互的验证是确保系统行为正确性的重要方面。Mockito 提供了多种工具来验证这些交互。例如，使用 `inOrder` 对象来确保方法调用的顺序符合预期。 ```java InOrder inOrder = inOrder(object1, object2); inOrder.verify(object1).methodA(); inOrder.verify(object2).methodB(); inOrder.verify(object1).methodC(); ``` 通过上述代码，我们创建了一个 `InOrder` 对象来检查 `object1` 是否先调用了 `methodA`，然后 `object2` 调用了 `methodB`，最后 `object1` 又调用了 `methodC`。 ### 3.2.2 验证回调和监听器的行为 对于涉及事件监听或回调的场景，Mockito 允许验证特定事件是否触发了相应的回调方法。这在测试异步处理或事件驱动的代码时特别有用。 ```java verify(callbackListener).onEvent(argThat(new CustomMatcher("eventData"))); ``` 这里使用了一个自定义匹配器来确保 `onEvent` 方法被正确地触发，并且接收到符合预期的数据。 ## 3.3 测试遗留代码 ### 3.3.1 使用Mockito测试遗留代码的策略 遗留代码往往缺乏良好的测试结构，但使用Mockito可以帮助我们隔离待测试组件并模拟复杂的依赖。一种策略是将Mock对象注入到遗留组件中。 ```java LegacyService service = mock(LegacyService.class); when(service.methodToTest()).thenCallRealMethod(); when(service.dependencyMethod()).thenReturn(expectedResult); service.run(); // 这里可以验证 service 的行为或其与 mock dependencyMethod 的交互 ``` 在此示例中，`LegacyService` 是一个遗留类，我们通过Mockito对它的某个方法进行测试。`thenCallRealMethod` 用于调用实际的方法，而 `when(service.dependencyMethod())` 则用于模拟依赖方法的返回值。 ### 3.3.2 应对不可Mock对象的解决方案 有时候，一些类或对象可能是不可Mock的，例如由于final类、私有方法等。这种情况下，可以采取一些替代策略： 1. **提取接口**：如果类的某些方法无法Mock，可以考虑提取接口并使用该接口进行Mock。 2. **使用PowerMock**：当需要Mock静态方法、构造函数或final类时，可以使用PowerMock框架。PowerMock提供了扩展Mockito的功能，允许Mock更多难以Mock的场景。 3. **使用反射**：另一种选择是通过Java的反射API来直接访问和修改私有或受保护的字段。 ```java Field field = LegacyService.class.getDeclaredField("privateField"); field.setAccessible(true); field.set(service, newValue); ``` 上述代码展示了如何使用Java反射API来设置 `LegacyService` 类中私有字段的值，这在无法直接Mock该字段时非常有用。 通过上述策略和技巧，即使是复杂的遗留代码，也可以在不实际修改原有代码的情况下进行单元测试，从而提高代码质量并减少维护成本。 # 4. Mockito的高级特性与最佳实践 ## 4.1 使用BDD风格的Mockito API ### 4.1.1 BDD风格的优势与实践 行为驱动开发（Behavior-Driven Development, BDD）是敏捷软件开发中的一种方法，它鼓励软件项目中的开发者、QA和非技术或商业参与者之间的协作。在测试框架中，BDD提供了一种编写更接近自然语言测试用例的方式，从而使测试用例的意图更加清晰，并促进团队沟通。 Mockito提供了一套BDD风格的API，使得测试用例能够以Given-When-Then的形式编写。这种方式不仅能够清晰地表达测试的意图，还能增强测试的可读性和可维护性。 下面是一个使用BDD风格API的简单示例： ```java // Given (预设条件) given(userRepository.findByName("John")).willReturn(Optional.of(new User("John", 30))); // When (触发动作) Optional<User> user = userRepository.findByName("John"); // Then (预期结果) assertThat(user).isPresent(); assertThat(user.get().getName()).isEqualTo("John"); ``` BDD风格API的优势在于其能够使测试用例更加清晰，符合业务需求，并且易于理解。它鼓励开发者从用户的角度去思考问题，提供更加符合业务的测试用例。 ### 4.1.2 BDD风格的API示例 在BDD风格API中，我们通常使用`given()`, `when()`, `then()`等方法来组织我们的测试代码。这些方法使得测试代码更易于阅读和理解，尤其是在团队协作的环境中。 ```java // BDD风格的API示例 public class UserTest { private UserRepository userRepository = mock(UserRepository.class); private UserService userService = new UserService(userRepository); @Test public void shouldFindUserByName() { // Given (预设条件) given(userRepository.findByName("John")).willReturn(Optional.of(new User("John", 30))); // When (触发动作) Optional<User> user = userService.findUserByName("John"); // Then (预期结果) assertThat(user).isPresent(); assertThat(user.get().getName()).isEqualTo("John"); } } ``` 以上代码使用了BDD风格的API来构建了一个测试用例，清晰地表达了测试的条件、执行的动作和预期的结果。 ## 4.2 与其他测试框架的集成 ### 4.2.1 集成JUnit和TestNG Mockito与JUnit和TestNG是Java开发中常用的单元测试和集成测试框架。Mockito可以很好地与JUnit和TestNG集成，提供丰富的Mock和Stubbing功能，以便更有效地进行测试。 #### JUnit集成 Mockito与JUnit的集成非常简单，可以通过添加依赖到项目的构建配置中来实现： ```xml <!-- Maven依赖配置 --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.2</version> <scope>test</scope> </dependency> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>3.5.13</version> <scope>test</scope> </dependency> ``` 通过上述配置，即可在JUnit测试中使用Mockito进行Mock对象的创建和配置。 #### TestNG集成 对于TestNG，集成方式类似： ```xml <!-- Maven依赖配置 --> <dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>7.1.0</version> <scope>test</scope> </dependency> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>3.5.13</version> <scope>test</scope</dependency> ``` 在TestNG的测试类中，可以使用注解来标记测试方法，并使用Mockito提供的功能来编写测试逻辑。 ### 4.2.2 集成Spock框架 Spock是一个基于Groovy的测试框架，提供了更丰富的语法来描述测试用例。Spock和Mockito之间的集成提供了编写行为驱动测试的强大能力。 #### 集成Spock 要将Mockito与Spock集成，首先需要添加依赖： ```groovy // Gradle依赖配置 dependencies { testImplementation "org.spockframework:spock-core:2.0-groovy-3.0" testImplementation "org.mockito:mockito-core:3.5.13" } ``` 之后，可以使用Spock的特性来编写测试用例，同时利用Mockito来创建Mock对象和配置行为。 ```groovy class UserSpec extends Specification { def userRepository = Mock(UserRepository) def userService = new UserService(userRepository) def "should find user by name"() { given: def user = new User("John", 30) userRepository.findByName("John") >> Optional.of(user) when: Optional<User> result = userService.findUserByName("John") then: result.isPresent() result.get().getName() == "John" } } ``` 在这个例子中，我们利用了Mockito的`>>`操作符来配置Mock对象的行为，并使用Spock的特性来编写测试用例。 ## 4.3 最佳实践与测试维护 ### 4.3.1 编写可读性强的Mockito测试 为了编写可读性强的Mockito测试，以下是一些推荐的最佳实践： - 使用BDD风格的API来提高测试用例的可读性。 - 在测试用例的命名上使用有意义的名称，体现测试的意图。 - 对于复杂的测试逻辑，使用辅助方法来封装重复代码。 - 避免使用魔法值和硬编码的字符串，使用常量或枚举来代替。 ### 4.3.2 维护测试代码与生产代码的同步 测试代码和生产代码应该保持同步更新。以下是一些维护测试代码的实践： - 当生产代码发生变化时，同步更新相应的测试代码。 - 定期审查测试覆盖率，确保重要的业务逻辑都有对应的测试。 - 删除无用或过时的测试用例，保持测试套件的精炼。 - 定期重构测试代码，确保测试用例的清晰和高效。 通过遵循这些最佳实践，可以确保测试代码的长期维护性和可靠性。 # 5. Mockito实践案例分析 Mockito框架不仅在理论上提供了强大的测试功能，而且在实际应用中同样表现出色。在本章中，我们将通过三个实际案例深入分析Mockito在不同场景中的应用与效果。 ## 实践案例一：Web服务的单元测试 ### 案例背景 设想一个简单的Web服务，该服务通过REST API接收客户端的请求，并返回数据。为了保证Web服务的质量，我们需要对相关的方法进行单元测试。但这些方法往往依赖于外部服务或数据库，直接测试并不现实。这时，我们可以利用Mockito来模拟这些依赖。 ### 案例分析与应用 为了简化案例，我们假设有一个`UserService`类，它通过调用`UserRepository`来获取用户信息，并返回给Web服务的请求处理方法。下面是`UserService`的一个简化版本： ```java public class UserService { private UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } public User getUserById(Long id) { return userRepository.findById(id).orElse(null); } } ``` 接下来，我们编写测试用例来验证`UserService`的`getUserById`方法。首先，我们需要模拟`UserRepository`接口： ```java @ExtendWith(MockitoExtension.class) class UserServiceTest { @Mock private UserRepository userRepository; @InjectMocks private UserService userService; @Test void getUserByIdTest() { User mockUser = new User("John Doe", 30); Mockito.when(userRepository.findById(1L)).thenReturn(Optional.of(mockUser)); User result = userService.getUserById(1L); assertNotNull(result); assertEquals("John Doe", result.getName()); assertEquals(30, result.getAge().intValue()); Mockito.verify(userRepository, Mockito.times(1)).findById(1L); } } ``` 这个测试用例演示了Mockito基础实践：创建一个模拟对象，并配置其行为来响应特定的方法调用。通过使用`@Mock`注解，我们告诉Mockito框架创建`UserRepository`接口的模拟对象。然后通过`@InjectMocks`注解自动注入模拟对象到`UserService`实例中。`when(...).thenReturn(...)`方法链用于配置模拟对象的预期行为。最后，我们使用`assertNotNull(...)`和`assertEquals(...)`来验证`getUserById`方法的返回结果，同时使用`verify(...)`来确认方法是否被正确调用了一次。 以上案例展示了在Web服务的单元测试中，Mockito如何帮助我们模拟和测试依赖于外部服务或数据库的业务逻辑。 ## 实践案例二：数据库操作的Mock测试 ### 案例背景 在开发中，数据库操作通常是测试的难点之一。真实的数据环境可能不稳定，或者测试数据的创建与销毁会带来额外的开销。在这种情况下，使用Mockito来模拟数据库操作能大幅提高测试效率。 ### 案例分析与应用 为了展示如何使用Mockito进行数据库操作的模拟测试，我们构建一个`OrderService`类，该类负责处理订单的创建和存储： ```java public class OrderService { private OrderRepository orderRepository; public OrderService(OrderRepository orderRepository) { this.orderRepository = orderRepository; } public void createOrder(Order order) { orderRepository.save(order); } } ``` 我们需要测试`createOrder`方法，但又不想进行真实的数据存储。我们可以使用Mockito来模拟`OrderRepository`： ```java @ExtendWith(MockitoExtension.class) class OrderServiceTest { @Mock private OrderRepository orderRepository; @InjectMocks private OrderService orderService; @Test void createOrderTest() { Order mockOrder = new Order("ProductA", 10); orderService.createOrder(mockOrder); Mockito.verify(orderRepository, Mockito.times(1)).save(mockOrder); } } ``` 在这个测试中，我们模拟了`OrderRepository`的`save`方法，确保当`createOrder`被调用时，`save`方法会被执行一次。与前面的案例类似，我们使用`@Mock`注解创建模拟对象，然后通过`@InjectMocks`将模拟对象注入到`OrderService`中。这个测试虽然简单，但它展示了在数据库操作测试中Mockito的直接应用。 ## 实践案例三：多线程环境下的Mock测试 ### 案例背景 多线程环境下的单元测试是一个复杂的话题，因为线程的并发行为难以预测和控制。Mockito可以用来模拟对象的行为，但不会模拟对象所在线程的行为。为了确保测试的准确性，我们可能需要模拟线程间的交互。 ### 案例分析与应用 考虑一个简单的场景，其中`TaskManager`类负责管理任务的执行，可能使用了线程池来并发执行任务： ```java public class TaskManager { private ExecutorService executorService; public TaskManager(ExecutorService executorService) { this.executorService = executorService; } public void submitTask(Runnable task) { executorService.submit(task); } } ``` 一个单元测试可能需要验证`submitTask`方法的行为，即使无法直接模拟线程的行为，我们也可以通过验证方法调用的逻辑来间接测试： ```java @ExtendWith(MockitoExtension.class) class TaskManagerTest { @Mock private ExecutorService executorService; @InjectMocks private TaskManager taskManager; @Test void submitTaskTest() { Runnable mockTask = Mockito.mock(Runnable.class); taskManager.submitTask(mockTask); Mockito.verify(executorService, Mockito.times(1)).submit(mockTask); } } ``` 在上述测试案例中，我们使用`@Mock`来模拟`ExecutorService`对象，然后验证`submitTask`方法是否正确地调用了`submit`方法。虽然我们没有直接测试多线程的行为，但验证了`TaskManager`是否正确地与线程池交互。 在本章中，我们通过三个实践案例展示了Mockito在不同场景下的应用。每个案例都突出了Mockito如何解决实际问题，提高了测试的可靠性和效率。通过这些案例，我们也可以看到Mockito在保证单元测试隔离性的同时，如何支持复杂的交互和多线程测试。