万字长文：一文详解单元测试干了什么

原创离澈阿里云开发者

阿里妹导读

好的单元测试不仅可以验证代码结构设计的是否合理，而且可以提前发现代码中的漏洞，将线上风险扼杀在摇篮中。本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望能帮到每一位同学。

导读

随着我们各种“code大赛”的不断推进，大家对于单元测试也越发重视。好的单元测试不仅可以验证代码结构设计得是否合理，而且可以提前发现代码中的漏洞，将线上风险扼杀在摇篮中。写好单元测试是每一位程序员的基本功，但是有不少同学对于单元测试有些知其然但不知其所以然，对于单元测试的底层逻辑并未深入研究过，只停留在使用的层面。本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望能帮到每一位同学。

单元测试框架

Java中存在很多单元测试框架，每种框架有着自己独特的特点，根据不同的需求和团队要求，每位同学所使用的框架不尽相同，目前主流的测试框架有且不仅有以下几种：

JUnit

JUnit是Java中最常用的单元测试框架。该框架提供了丰富的测试与断言方法，例如：assertNull、assertTrue、assertEquals等，使用方法比较简单。JUnit目前已经更新到JUnit5版本，该版本提供了更多的新特性，例如：动态测试，依赖注入等，使得该框架更为健壮。

官网介绍：https://junit.org/junit5/

TestNG

TestNG是Java中的另一种测试框架，集团内使用的较为小众。该框架的设计是受了JUnit的启发，初衷是为了更好地支持从单元测试到集成测试的各个方面，用来完成一些JUnit所不能完成的测试任务。该框架较JUnit相比，功能更加强大，提供了更多的高级特性，例如：测试套件、数据驱动测试、依赖测试、并行测试等。在更复杂的测试场景（如参数化测试、依赖测试等）中，TestNG的表现更加优异。

官网介绍：https://testng.org/

Spock

Spock是基于Groovy语言编写的测试框架，该框架可以用来测试Java和Groovy的代码程序。Spock用来写测试代码的语言十分优美、表达力强，这一优点大大提高了测试代码的可读性和可维护性。Spock框架融合了JUnit、jMock、RSpec、Groovy、Scala和Vulcans等多种框架和语言的优点，旨在提供一套强大的测试平台。

官网介绍：https://spockframework.org/

Mockito

Mockito不是一个完整的单元测试框架，而是专注于mock对象的创建、验证。它通常与JUnit或TestNG结合使用来简化对复杂依赖的测试。是目前集团内最主流的测试框架，下文中将对该框架进行详细阐述。

官网介绍：http://site.mockito.org/

EasyMock

EasyMock是一套通过简单方法对于给定的接口生成mock对象的类库，通过使用Java代理机制动态生成模拟对象。该框架提供对接口的模拟，能够通过录制、回放、检查三步来完成大体的测试过程，可以验证方法的调用种类、次数、顺序等，还可以令mock对象返回指定的值或抛出指定异常。开发者通过EasyMock可以方便的构造mock对象而忽略对象背后真正的业务逻辑。一般情况下，EasyMock与JUnit或TestNG配合使用。

官网介绍：https://easymock.org/

PowerMock

PowerMock是一种用于Java单元测试的框架，它扩展了其他mocking框架的能力，比如EasyMock和Mockito。PowerMock的主要特点是它可以mock静态方法、私有方法、final方法、构造函数，甚至系统类（如System、String等），这些通常是传统mocking框架所做不到的。有了这些功能，PowerMock在一些复杂场景下进行单元测试更加方便。虽然PowerMock提供了强大的功能，但由于它修改了类加载器和字节码操作，可能会导致一些测试方法与JVM或第三方库之间的兼容性问题。所以，在使用PowerMock时需要权衡其提供的功能和可能带来的复杂性。

ps：由于PowerMock的执行速度问题（每个测试类都需要重启spring的TestContext），我们团队内部不建议使用该框架。

官网介绍：https://github.com/powermock/powermock

JMock

JMock是一种用于Java单元测试的框架，属于一种轻量级框架，该框架采用了行为驱动开发（BDD）的测试风格。用来在单元测试中mock接口或类的依赖项，对代码进行隔离测试，而无需关心整个系统的其他部分。JMock支持通过声明式的方式来指定对象间的交互行为。

官网介绍：http://jmock.org/

大部分开发者在使用这些测试框架时，不会独立使用其中一种，而是会结合使用，例如，可以在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框架运行单元测试的常用底层逻辑，对其中的一些高级特性并未深入探讨，感兴趣的小伙伴可以自行研究。单元测试是开发中一个庞大的分支，并非一篇文章能论述得清楚。当然，如果此文能引起你对单元测试底层逻辑的兴趣，那便是本文最大的价值了。

继续滑动看下一个