背景

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

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

@RunWith(MockitoJUnitRunner.class) // 注意这一行
public class MyTest {
	@Mock
	List<String> mockedList;
	
	@Test
	public 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，也就是 MockitoJUnitRunner
            currentScheduler.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.java

public class MockitoJUnitRunner extends Runner implements Filterable {
	// 第 149 行
	private final InternalRunner runner;

	// 第 161 行
	@Override
    public 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 行
 	@Override
    public 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 注解
                @Override
                protected Statement withBefores(
                        FrameworkMethod method, final Object target, Statement statement) {
                    this.target = target;
                    final Statement base = super.withBefores(method, target, statement);
                    return new Statement() {
                        @Override
                        public 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 方法，嵌入了一层注解解析逻辑。