| 编辑推荐: |
本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望对你的学习有帮助。
本文来自于微信公众号阿里云开发者，由火龙果软件Linda编辑、推荐。 |
|
阿里妹导读
好的单元测试不仅可以验证代码结构设计的是否合理，而且可以提前发现代码中的漏洞，将线上风险扼杀在摇篮中。本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望能帮到每一位同学。
导读
随着我们各种“code大赛”的不断推进，大家对于单元测试也越发重视。好的单元测试不仅可以验证代码结构设计得是否合理，而且可以提前发现代码中的漏洞，将线上风险扼杀在摇篮中。写好单元测试是每一位程序员的基本功，但是有不少同学对于单元测试有些知其然但不知其所以然，对于单元测试的底层逻辑并未深入研究过，只停留在使用的层面。本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望能帮到每一位同学。
单元测试框架
Java中存在很多单元测试框架，每种框架有着自己独特的特点，根据不同的需求和团队要求，每位同学所使用的框架不尽相同，目前主流的测试框架有且不仅有以下几种：
JUnit
JUnit是Java中最常用的单元测试框架。该框架提供了丰富的测试与断言方法，例如：assertNull、assertTrue、assertEquals等，使用方法比较简单。JUnit目前已经更新到JUnit5版本，该版本提供了更多的新特性，例如：动态测试，依赖注入等，使得该框架更为健壮。
TestNG
TestNG是Java中的另一种测试框架，集团内使用的较为小众。该框架的设计是受了JUnit的启发，初衷是为了更好地支持从单元测试到集成测试的各个方面，用来完成一些JUnit所不能完成的测试任务。该框架较JUnit相比，功能更加强大，提供了更多的高级特性，例如：测试套件、数据驱动测试、依赖测试、并行测试等。在更复杂的测试场景（如参数化测试、依赖测试等）中，TestNG的表现更加优异。
Spock
Spock是基于Groovy语言编写的测试框架，该框架可以用来测试Java和Groovy的代码程序。Spock用来写测试代码的语言十分优美、表达力强，这一优点大大提高了测试代码的可读性和可维护性。Spock框架融合了JUnit、jMock、RSpec、Groovy、Scala和Vulcans等多种框架和语言的优点，旨在提供一套强大的测试平台。
Mockito
Mockito不是一个完整的单元测试框架，而是专注于mock对象的创建、验证。它通常与JUnit或TestNG结合使用来简化对复杂依赖的测试。是目前集团内最主流的测试框架，下文中将对该框架进行详细阐述。
EasyMock
EasyMock是一套通过简单方法对于给定的接口生成mock对象的类库，通过使用Java代理机制动态生成模拟对象。该框架提供对接口的模拟，能够通过录制、回放、检查三步来完成大体的测试过程，可以验证方法的调用种类、次数、顺序等，还可以令mock对象返回指定的值或抛出指定异常。开发者通过EasyMock可以方便的构造mock对象而忽略对象背后真正的业务逻辑。一般情况下，EasyMock与JUnit或TestNG配合使用。
PowerMock
PowerMock是一种用于Java单元测试的框架，它扩展了其他mocking框架的能力，比如EasyMock和Mockito。PowerMock的主要特点是它可以mock静态方法、私有方法、final方法、构造函数，甚至系统类（如System、String等），这些通常是传统mocking框架所做不到的。有了这些功能，PowerMock在一些复杂场景下进行单元测试更加方便。虽然PowerMock提供了强大的功能，但由于它修改了类加载器和字节码操作，可能会导致一些测试方法与JVM或第三方库之间的兼容性问题。所以，在使用PowerMock时需要权衡其提供的功能和可能带来的复杂性。
ps：由于PowerMock的执行速度问题（每个测试类都需要重启spring的TestContext），我们团队内部不建议使用该框架。
JMock
JMock是一种用于Java单元测试的框架，属于一种轻量级框架，该框架采用了行为驱动开发（BDD）的测试风格。用来在单元测试中mock接口或类的依赖项，对代码进行隔离测试，而无需关心整个系统的其他部分。JMock支持通过声明式的方式来指定对象间的交互行为。
大部分开发者在使用这些测试框架时，不会独立使用其中一种，而是会结合使用，例如，可以在JUnit或TestNG的基础上使用Mockito来创建和使用mock对象，来完成比较复杂的测试任务。每个框架都有其独特的优点与缺点，选择哪个框架通常取决于个人偏好、项目需求以及现有代码库的兼容性。
当然，实际开发中的单元测试框架远不止以上所提到的这些，还有一些同样优秀的框架在本文中没有介绍，例如：Selenium、Cucumber、Appium等，感兴趣的读者可以自行学习。
我们在用什么？
目前集团内主流的单元测试框架用的是Mockito框架，该框架的单元测试流程为：
以下面的代码为例，展示一下单元测试的常用写法：
@Autowired
private BenefitRecordQueryServiceI benefitRecordQueryServiceI;
@Override
public List<BenefitRecordExtendVO> queryBenefitRecordList(Long
companyId, String scene) {
Validate.notNull(companyId, "companyId cannot
be null");
Validate.notBlank(scene, "scene cannot be
null");
BenefitRecordQueryParam param = new BenefitRecordQueryParam();
param.setCompanyId(companyId);
param.setScene(scene);
MultiResponse<BenefitRecordExtendDTO> res
= benefitRecordQueryServiceI
.pageQueryBenefitRecordWithExtendAttrs(param);
if (res == null || !res.isSuccess()) {
log.error("pageQueryBenefitRecordWithExtendAttrs
error, companyId:{}, scene:{}, res:{}",companyId,
scene, JSON.toJSONString(res));
throw new SupplierFosterException("pageQueryBenefitRecordWithExtendAttrs
error");
}
return DataObjectUtils.transferDeep(res.getData(),
BenefitRecordExtendVO.class);
}
|
对以上代码写一段合格的单元测试是每一位程序员的基本功，无非就是@InjectMocks、@Mock、Mockito.when()、Mockito.verify()等一系列操作。当然，我们也是这样做的：
@InjectMocks
private BenefitAdaptorImpl benefitAdaptor;
@Mock
private BenefitRecordQueryServiceI benefitRecordQueryServiceI;
@Test
public void testQueryBenefitRecordListWhenSuccess()
{
Long companyId = 123L;
String scene = "cnfm";
MultiResponse<BenefitRecordExtendDTO>
res = new MultiResponse<>();
List<BenefitRecordExtendDTO> resList
= new ArrayList<>();
BenefitRecordExtendDTO benefitRecordExtendDTO
= new BenefitRecordExtendDTO();
benefitRecordExtendDTO.setBenefitCode("rfq");
resList.add(benefitRecordExtendDTO);
res.setSuccess(true);
res.setData(resList);
Mockito.when(benefitRecordQueryServiceI.pageQueryBenefitRecordWithExtendAttrs(
Mockito.any())).thenReturn(res);
List<BenefitRecordExtendVO> result
= benefitAdaptor.queryBenefitRecordList(companyId,
scene);
Assert.assertEquals(1, result.size());
BenefitRecordExtendVO benefitRecordRes = result.get(0);
Assert.assertNotNull(benefitRecordRes);
Assert.assertEquals("rfq", benefitRecordRes.getBenefitCode());
Mockito.verify(benefitRecordQueryServiceI).pageQueryBenefitRecordWithExtendAttrs(
Mockito.any());
}
|
点击，运行，没问题！ok，继续写下一段，等等～真的没问题了吗？那请尝试回答一下下面的几个问题：
@InjectMocks干了什么，mock的benefitAdaptor对象有什么特性？
@Mock干了什么，mock的benefitRecordQueryServiceI对象有什么特性？
Mockito.when().thenReturn()干了什么，如何模拟方法调用的？
Mockito.verify()干了什么，如何验证方法的调用运行？
如果你能清晰的回答以上4个问题，那么这篇文章对于你来说是一个温故的作用；如果回答不上来，那么阅读这篇文章来知新吧！
mockito怎么运行的？
@RunWith(MockitoJUnitRunner.class)
@RunWith(MockitoJUnitRunner.class)是Junit中的一个注解，用来指定测试运行环境(MockitoJUnitRunner)。该注解的主要作用就是自动初始化mock对象。
在Mockito 1.9.5之前，初始化mock对象需要通过手动的显示调用：
@Before
public void initMocks() {
MockitoAnnotations.initMocks(this);
} |
Mockito 1.9.5之后，将该初始化过程集成到MockitoJUnitRunner中，仅需要一个注解，就可以完成mock对象的注入，让我们一起看一下MockitoJUnitRunner到底是怎么执行的，以Mockito
2.23.0版本为例：
看起来MockitoAnnotations.initMocks(this)可能不是在MockitoJUnitRunner的构造函数中直接调用的。相反，MockitoJUnitRunner可能在另外一个封装层（如StrictRunner或RunnerFactory中创建的某个Runner）中处理初始化mock的逻辑：
可以看出，InternalRunner接口的实现类DefaultInternalRunner的构造函数中调用了MockitoAnnotations.initMocks(this)来初始化mock对象。这样做的好处主要有两点：1）代码更加简洁；2）在运行测试用例之前保证对象都已经mock完成。
至于MockitoAnnotations.initMocks(this)是怎么mock对象的，请继续往下看。
@InjectMocks
@InjectMocks是Mockito测试框架提供的一个注解，会自动将mock对象注入到被测试类的实例中，来创建和初始化那些需要被注入的mock对象，被测试对象通常是要被进行单元测试的类。
@InjectMocks注解如下：
根据官网对@InjectMocks的介绍，注入mock对象的方式有3种：
构造器注入：Mockito会寻找被标注类的构造器，并尝试使用可用的mock对象作为参数来实例化类。它首先尝试使用最多参数的构造器，如果失败，则尝试较少参数的构造器。
属性注入：如果构造器注入不可行或者不成功，Mockito会尝试将mock对象直接设置到被标注类的属性中，这包括私有属性。它会通过反射来忽略访问修饰符，直接向属性赋值。
方法注入：如果前两种方式都不可行，Mockito会尝试调用类中的setter方法来注入mock对象。
仅仅知道这3种注入方式，并不能帮我们深入理解Mockito到底是怎么运行的，那么该注解的执行是怎么样的呢？
前文提到，Mockito在处理注解时，主要是通过MockitoAnnotations.initMocks(this)方法进入。首先，这个方法会创建一个注解引擎-AnnotationEngine：
这个引擎会对测试类进行扫描，寻找所有Mockito注解字段（包括@Mock，@Spy，@Captor和@InjectMocks），每一种注解有着相对应的处理器进行相应的处理，以InjectingAnnotationEngine为例：
通过injectMocks和injectMocksOnFields方法可以看出，Mockito是会尝试在被测试类中找到一个构造器，该构造器的参数与现有的mock对象是相匹配的，并使用这些mock对象实例化@InjectMocks注解的字段。如果没有找到相匹配的构造器，Mockito将使用属性注入的方式直接设置字段的值，或者通过setter方法进行注入。
@InjectMocks注解的功能是由Mockito内部的几个类协同工作实现的，逻辑处理十分复杂，涉及到许多边界情况的处理和错误管理，例如，需要处理多个构造器、避免循环依赖、选择最佳的注入策略等。下面通过一段伪代码对上述的流程进行逻辑概括：
public class MockitoAnnotations {
public static void initMocks(Object test) {
AnnotationEngine annotationEngine = ...;
annotationEngine.process(test.getClass(), test);
}
}
public class InjectMocksAnnotationEngine implements
AnnotationEngine {
public void process(Class<?> clazz, Object
testInstance) {
// 获取所有 @Mock 标注的字段
Set<Field> mockFields = ...;
// 获取所有 @InjectMocks 标注的字段
Set<Field> injectMocksFields = ...;
for (Field injectMocksField : injectMocksFields)
{
// 创建 @InjectMocks 标注字段的实例
Object fieldInstance = createInstance(injectMocksField.getType());
injectMocksField.setAccessible(true);
// 将实例设置到测试类的字段中
injectMocksField.set(testInstance, fieldInstance);
PropertySetterInjector propertySetterInjector
= new PropertySetterInjector(mockFields);
ConstructorInjector constructorInjector = new
ConstructorInjector(mockFields);
if (!constructorInjector.tryConstructorInjection(fieldInstance,
injectMocksField)) {
propertySetterInjector.tryPropertyOrSetterInjection(fieldInstance,
injectMocksField);
}
}
}
}
public class ConstructorInjector {
public boolean tryConstructorInjection(Object
fieldInstance, Field injectMocksField) {
// 使用反射尝试通过构造器注入 mock 对象
}
}
public class PropertySetterInjector {
public void tryPropertyOrSetterInjection(Object
fieldInstance, Field injectMocksField) {
// 使用反射尝试通过属性或setter方法注入 mock 对象
}
} |
对于该注解的执行逻辑，可以总结为以下4步：
1.注解处理器的初始化：首先调用MockitoAnnotations.initMocks(this)，或者使用MockitoJUnitRunner或JUnit的MockitoExtension。这些方法会扫描测试类，查找所有由Mockito提供的注解（如@Mock，@Spy，@Captor，@InjectMocks）并进行处理。
2.mock对象的创建：对于每个使用@Mock注解的字段，Mockito会创建一个相应的mock对象。这是通过调用Mockito.mock()方法完成的（下文会讲怎么mock的），该方法使用动态代理或字节码操作来生成mock对象。
3.查找注入点：对于每个使用@InjectMocks注解的字段，Mockito会寻找变量注入的点。首先，Mockito会选择参数最多的、参数完全匹配的构造器注入mock对象。如果没有合适的构造器，它会尝试属性注入，最后考虑setter方法。
4.注入过程：一旦找到注入点（构造器、属性或setter方法），Mockito使用反射API来完成注入过程。对于构造器，它会使用找到的mock对象实例化新对象。对于属性或setter方法，它会直接注入mock对象。
通过以上的步骤注入的mock对象，和Spring加载的对象有着明显的区别：
使用目的
@InjectMocks主要用于单元测试，注入的是mock对象，用来模拟真实对象的行为。
Spring的依赖注入用于实际的应用运行中，注入的是真实的、由Spring容器创建和管理的bean对象。
运行环境
@InjectMocks在测试环境中使用，不依赖Spring容器。
Spring依赖注入是在应用的生产环境中使用，依赖于Spring容器的生命周期和管理。
对象类型
使用@InjectMocks注入的对象是一个用于模拟的代理对象。
Spring中注入的对象是完全功能的实例。
生命周期
Mockito不负责mock对象的生命周期管理，一旦测试用例运行完毕，mock对象就会被丢弃。
Spring容器负责bean的整个生命周期，包括创建、初始化、注入、销毁等。
对象创建
@Mockito通过动态代理的方式创建mock对象。
Spring通过实例化类定义来创建bean。
@Mock
@Mock注解用于注入测试对象，该测试对象通常是被测试对象的依赖或者外部组件，主要用来标记需要模拟的类或者接口。注入之后，可以在测试中模拟该对象的行为和返回值，而忽略该对象中的依赖和外部组件的行为。
@Mock注解如下：
1.answer：此属性表示为mock对象指定一个默认的行为，这个行为将应用于所有未打桩的方法调用。它会接受一个Answers枚举类型的值。例如，Answers.RETURNS_DEFAULTS会使未配置打桩的方法返回对应类型的默认值（0、false、null等）。其他如Answers.RETURNS_SMART_NULLS可以返回智能空值，这些空值在使用时会抛出异常，并在异常信息中打印出哪个未打桩的方法被调用了。
2.stubOnly：表示是否创建一个仅用于打桩的mock对象，如果设置为true，创建的mock对象不会记录任何方法调用，也就不能用于验证方法是否被调用。
3.name：对mock对象的命名。命名mock对象有助于错误调试，当验证失败时，异常信息中会包含这个名称。
4.extraInterfaces：可以为mock对象实现一些其他接口。
5.serializable：表示需要mock对象是否应该是可序列化的，如果设置为true，生成的mock对象将会实现Serializable接口。这样的话，注入的mock对象可以在需要序列化和反序列化的测试场景中使用。
@Mock注解的逻辑入口和@InjectMocks一致，都是从MockitoAnnotations.initMocks(this)开始执行，同样创建一个AnnotationEngine引擎：
根据该引擎的执行可以看出，首先通过反射获取测试类中所有字段，检查带有@Mock注解的字段，并为这些字段创建mock对象并设置到相应的字段上：
会根据不同的注解找到不同的处理器进行mock对象的处理：
读取注解的中配置的属性并将其转换为Mockito的MockSettings对象，调用Mockito.mock()方法并传入字段的类型和设置，以便创建具有所需特性的mock对象：
真正创建mock对象的代码如下：
分析上面的代码，发现一共做了以下几件事：
1.调用createMockType方法，该方法基于提供的MockCreationSettings生成mock对象的类型；
2.从Plugins中获取InstantiatorProvider的实例，然后调用getInstantiator方法获取Instantiator。Instantiator是负责创建mock对象的组件；
3.使用Instantiator的newInstance方法创建第一步生成的类型的新对象；
4.创建MockMethodInterceptor拦截器对象，主要拦截对mock对象所进行的调用，并根据settings里的设置执行相应的逻辑；
5.检查mock对象是否实现了MockAccess接口。如果实现了，将mockMethodInterceptor设置为其拦截器；
6.返回创建的mock对象。
至此，通过@Mock自动注入mock对象的主要过程就结束了，主要包括mock对象类型的确定、实例的创建、拦截器的设置以及异常的处理。可以看出，逻辑还是非常复杂的。下面通过一段伪代码对上述的流程进行逻辑概括：
// MockitoAnnotations.initMocks方法的简化伪代码
public static void initMocks(Object testClassInstance)
{
Class<?> testClass = testClassInstance.getClass();
Field[] fields = testClass.getDeclaredFields();
for (Field field : fields) {
if (field.isAnnotationPresent(Mock.class)) {
Mock mock = field.getAnnotation(Mock.class);
Object mockObject = createMockObject(field.getType(),
mock);
field.setAccessible(true);
field.set(testClassInstance, mockObject);
}
}
}
private static Object createMockObject(Class<?>
fieldType, Mock mockAnnotation) {
// 创建mock配置
MockSettings mockSettings = configureMockSettings(mockAnnotation);
// 使用Mockito API创建mock对象
return Mockito.mock(fieldType, mockSettings);
}
private static MockSettings configureMockSettings(Mock
mockAnnotation) {
// 根据@Mock注解的属性配置MockSettings
MockSettings mockSettings = Mockito.withSettings();
if (!"".equals(mockAnnotation.name()))
{
mockSettings.name(mockAnnotation.name());
}
if (mockAnnotation.stubOnly()) {
mockSettings.stubOnly();
}
// 其他配置参数
mockSettings.defaultAnswer(mockAnnotation.answer());
return mockSettings;
}
// Mockito.mock方法的简化伪代码
public static <T> T mock(Class<T>
classToMock, MockSettings mockSettings) {
// 检查是否可以被mock
if (isNotMockable(classToMock)) {
throw new MockitoException("Cannot mock/spy
class: " + classToMock.getName());
}
// 创建mock设置，如果未提供则使用默认设置
if (mockSettings == null) {
mockSettings = withSettings();
// 创建mock对象
T mockInstance = createMockInstance(classToMock,
mockSetting
// 返回mock对象
return mockInstance;
}
private static <T> T createMockInstance(Class<T>
classToMock, MockSettings mockSettings) {
// 根据mock设置创建一个MockCreationSettings对象
MockCreationSettings<T> settings = new
MockCreationSettings<>(classToMock, mockSetting
// 获取MockMaker插件，它负责创建mock实例
MockMaker mockMaker = Plugins.getMockMaker
// 使用MockMaker创建mock实例
T mock = mockMaker.createMock(settings, new
MockHandlerImpl<T>(settings
// 返回创建的mock实例
return mock;
} |
对于该注解的执行原理，可以总结为以下4步：
1.注解处理器的初始化：首先调用MockitoAnnotations.initMocks(this)，或者使用MockitoJUnitRunner或JUnit的MockitoExtension。这些方法会扫描测试类，查找@Mock注解标记的属性。
2.配置注解属性：根据注解参数创建MockCreationSettings对象，它包含了创建mock对象所需的所有设置。
3.Mock对象的创建：使用Mockito内部的MockMaker实例和前面步骤中创建的MockCreationSettings，生成mock对象。
4.方法Mock对象到字段：通过反射将生成的mock对象赋给测试类中的对应字段。
Mockito.when()
Mockito.when()是Mockito框架中的一个核心功能，该功能用于为mock对象的方法调用指定一个预期的行为。例如：返回一个特定的值、抛出一个异常或者执行一个特定的动作。然而，Mockito.when()只用来设置打桩状态，而不会定义预期的返回值，一般结合doReturn()、doThrow()、
doAnswer()、doNothing()、doCallRealMethod()等方法一起使用来指定函数调用的预期行为。
当Mockito.when()被调用时，会获取一个线程安全的MockingProgress实例来设置mock对象的打桩状态。该过程会涉及到线程局部变量的操作，以确保验证状态不会与其他线程的操作冲突。
通过pullOngoingStubbing()方法提取当前正在进行的打桩对象：
首先会获取当前的OngoingStubbing，该字段存储着当前线程的正在进行的打桩对象，然后清除该对象，防止未来的打桩操作错误地使用旧的打桩对象，最后返回该对象。OngoingStubbing对象并无法分析开发者设置预期行为，需要链式调用thenReturn()、thenThrow()
等方法。例如：Mockito.when().thenReturn()。
下面以thenReturn()为例分析：
当OngoingStubbing对象链式调用thenReturn()之后，首先会通过new Returns(value)实例化一个返回指定值的对象并调用thenAnswer()方法：
从上面代码看，主要是将设置的预期行为添加到Mockito.when()生成的OngoingStubbing对象中，可以分为以下流程：
1.获取打桩实例：从invocationForStubbing中获取代表打桩调用的Invocation对象。
2.打桩完成通知：MockingProgress对象打桩过程已经完成，这一步可能会更新其内部状态。
3.回答验证：如果Answer实例实现了ValidableAnswer接口，那么对第一步获取的Invocation对象进行验证。
4.同步打桩列表：在synchronized代码块中，同步打桩列表stubbed。
5.添加或更新打桩列表：如果打桩对象设置为连续调用，将Answer对象设置到打桩列表的首位。否则，将创建一个新的StubbedInvocationMatcher实例并设置到打桩列表首位。
6.返回打桩匹配器：返回打桩列表中第一个元素，并强转为匹配器类型。
由于打桩操作通常遵循“LIFO”规则，所以最后一个设置的Answer是最新被调用的，也就是说，后续的打桩配置会覆盖之前的打桩配置。
Mockito.verify()
Mockito.verify()方法是Mockito框架中的一个核心功能，该功能用于验证一个mock对象的某个方法是否被调用，以及调用的次数和参数是否一致。
当Mockito.verify()被调用时，大致的运行流程如下：
verify()方法会创建一个新的VerificationMode实例，通常是调用1次的验证模式。所以，当验证函数只调用1次的情况下在verify函数中可以省略times的参数。
分析上面的代码，发现一共做了以下几件事：
1.mock对象检查：通过mockingDetails(mock)检查传入的对象是否真的是一个mock对象。
2.参数验证：确认mock对象是否仅用于打桩，而非验证。如果是一个仅用于打桩的mock对象，那么就不能对其进行验证。
3.通知验证开始：如果验证过程涉及监听器，调用VerificationStartedNotifier.notifyVerificationStarted()方法来通知所有的验证开始监听器。
4.获取MockingProgress：获取当前线程的MockingProgress实例来记录验证状态，这会涉及到线程局部变量的操作，以确保验证状态不会与其他线程的操作冲突。
5.延迟验证：使用maybeVerifyLazily()方法，该方法可能会修改传入的VerificationMode来延迟验证，当某个特定的方法调用时再进行验证。
6.开始验证：创建一个MockAwareVerificationMode实例并将其设置到MockingProgress中。这个实例包含mock对象、实际的验证模式和验证监听器。
7.结束验证：返回mock对象。
在verify()的实际调用中，还包含了对InOrder验证、验证超时等高级特性的支持，以及对异常处理和各种边界情况的处理，本文仅提供了一个验证流程上的分析。下面通过一段伪代码对上述的流程进行逻辑概括：
public class Mockito {
public static <T> T verify(T mock) {
return verify(mock, times(1));
}
public static <T> T verify(T mock, VerificationMode
mode) {
MockingProgress progress = MockingProgressImpl.threadSafeMockingProgress();
progress.verificationStarted(mode);
return mock;
}
}
public class MockHandlerImpl<T> implements
MockHandler<T> {
public Object handle(Invocation invocation)
throws Throwable {
MockingProgress progress = MockingProgressImpl.threadSafeMockingProgress();
VerificationMode verificationMode = progress.pullVerificationMode();
if (verificationMode != null) {
// 验证调用
verificationMode.verify(invocation);
return null;
} else {
// 执行实际的mock行为
return invocation.callRealMethod();
}
}
} |
结语
本文讲述了Mockito框架运行单元测试的常用底层逻辑，对其中的一些高级特性并未深入探讨，感兴趣的小伙伴可以自行研究。单元测试是开发中一个庞大的分支，并非一篇文章能论述得清楚。当然，如果此文能引起你对单元测试底层逻辑的兴趣，那便是本文最大的价值了。
|
