背景

上篇文章 研究了一下 JUnit 的基础原理，这篇来看看 Mockito 和 JUnit 交界的部分：@Mock 注解。

@Mock 注解可以看做一个语法糖，用更少的代码实现相同的 mock 功能。例如：

@RunWith(MockitoJUnitRunner.class) // 注意这一行
public class MyTest {@MockList<String> mockedList;@Testpublic void simpleTest() {Mockito.when(mockedList.size()).thenReturn(100);assertEquals(100, mockedList.size());}
}

这样声明 mockedList 更为清晰直观，胜过在测试里写 mockedList = Mockito.mock(List.class) ，特别是在许多测试方法中都要用到这样一个 mock 对象的时候。

那为什么说@Mock 注解是 Mockito 和 JUnit 交界的部分呢？注意最上面那行 @RunWith(MockitoJUnitRunner.class)，如果把这行去掉，@Mock 注解就失效了。（当然，还有别的方式也可以实现同样功能，比如增加 JUnit 的 @Rule 注解。）

毕竟，@Mock 注解需要由 Mockito 来解析。如果按照默认的方式执行 JUnit，JUnit 并不认识 @Mock 注解，自然也不会生效了。所以这里需要指定用 Mockito 提供的 MockitoJUnitRunner 来执行测试。

下面我们会看到，MockitoJUnitRunner 实际上是基于 JUnit 自身的默认 runner 的，但是加了一些功能，也就是对 Mockito 注解的解析。

（注：本文基于 Mockito 4.6.1 源码）

@Mock 注解是如何解析的

下面就来看看，执行上面的代码时，@Mock 注解是如何解析的。

阶段 1：Suite

上篇文章 讲过，JUnit 是通过 Runner 来执行测试的。Runner 是一个抽象类，而且 JUnit 考虑到了需要在 JUnit 自身 Runner 基础上增加功能的情况，所以写一个自己的 Runner 来执行测试不是一件难事。

通过 @RunWith(MockitoJUnitRunner.class) 这个注解，JUnit 就会用 MockitoJUnitRunner 来执行测试了。

但实际上，用来执行测试的 runner 对象并不是 MockitoJUnitRunner 类的实例，而是 JUnit 中的 Suite 类：

public class Suite extends ParentRunner<Runner> {// 略private final List<Runner> runners;// 略
}

Suite 类继承了 ParentRunner，同时又有一个 runners 成员对象是第三方提供的 runner 的列表（在这里就是包括 MockitoJUnitRunner），可以大致理解成“适配器模式”吧（把第三方 runner 适配到 ParentRunner）。

阶段 2：MockitoJUnitRunner

最终在某个地方，JUnit 的 ParentRunner 会在 runChildren 方法下调用 runChild，而 Suite 类覆写了这个方法，所以会走到 Suite 类中：

// 这是 ParentRunner 类 runChildren 方法的定义：
private void runChildren(final RunNotifier notifier) {final RunnerScheduler currentScheduler = scheduler;try {for (final T each : getFilteredChildren()) { // 这里会遍历 runners。在我们的例子中，只有一个 runner，也就是 MockitoJUnitRunnercurrentScheduler.schedule(new Runnable() {public void run() {ParentRunner.this.runChild(each, notifier); // 注意这里！}});}} finally {currentScheduler.finished();}
}// 这是 Suite 类 runChild 方法的定义
@Override
protected void runChild(Runner runner, final RunNotifier notifier) {runner.run(notifier); // 这里的 runner 就是我们的 MockitoJUnitRunner
}

这样就走到了我们的 MockitoJUnitRunner 中。

阶段 3：MockitoJUnitRunner

事实上，MockitoJUnitRunner 也封装了一个 runner 成员变量，会调用它来执行 run 方法：

// org/mockito/junit/MockitoJUnitRunner.javapublic class MockitoJUnitRunner extends Runner implements Filterable {// 第 149 行private final InternalRunner runner;// 第 161 行@Overridepublic void run(final RunNotifier notifier) {runner.run(notifier);}
}

这个 runner 是一个 DefaultInternalRunner 类的实例。

阶段 4：DefaultInternalRunner

到了 DefaultInternalRunner 这里发现，内部居然又封装了一个 runner 对象！

// org/mockito/internal/runners/DefaultInternalRunner.java
public class DefaultInternalRunner implements InternalRunner {private final BlockJUnit4ClassRunner runner;// ...// 第 105 行@Overridepublic void run(final RunNotifier notifier) {runner.run(notifier);}
}

但这个 runner 就是最终的 runner 了。它是一个继承自 BlockJUnit4ClassRunner 的匿名类的实例，覆写了 withBefores 方法：

// org/mockito/internal/runners/DefaultInternalRunner.java
// DefaultInternalRunner 的构建方法：
public DefaultInternalRunner(Class<?> testClass, final Supplier<MockitoTestListener> listenerSupplier)throws InitializationError {runner =new BlockJUnit4ClassRunner(testClass) {public Object target;private MockitoTestListener mockitoTestListener;// 注意这里！覆写了 withBefores 方法，从而实现在执行测试方法之前，先解析 @Mock 注解@Overrideprotected Statement withBefores(FrameworkMethod method, final Object target, Statement statement) {this.target = target;final Statement base = super.withBefores(method, target, statement);return new Statement() {@Overridepublic void evaluate() throws Throwable {AutoCloseable closeable;if (mockitoTestListener == null) {mockitoTestListener = listenerSupplier.get();Mockito.framework().addListener(mockitoTestListener);// 注意这里！解析 @Mock 注解// 这里的 target 就是测试类（这个例子里是 MyTest）的实例，用来执行测试closeable = MockitoAnnotations.openMocks(target);} else {closeable = null;}// 在解析了 @Mock 注解之后，才执行余下的步骤（包括执行测试方法本身try {base.evaluate();} finally {if (closeable != null) {closeable.close();}}}};}// 这里不怎么需要关注public void run(final RunNotifier notifier) {// ...   }};
}

至于 MockitoAnnotations.openMocks(target); 具体是怎么实现的，这里可以不必继续深究了，大概也能想到，就是根据 @Mock 或者 @Spy 等注解来实例化一个 mock 的类成员变量。

重点是，我们看到了 Mockito 如何通过替换 JUnit 的 runner 来“嵌入”这一层注解解析逻辑的。

小结

我们看到，Mockito 如何通过替换 JUnit 的 runner，覆写其 withBefores 方法，嵌入了一层注解解析逻辑。