好的单元测试不仅可以验证代码结构设计的是否合理，而且可以提前发现代码中的漏洞，将线上风险扼杀在摇篮中。本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望能帮到每一位同学。
随着我们各种“code大赛”的不断推进，大家对于单元测试也越发重视。好的单元测试不仅可以验证代码结构设计得是否合理，而且可以提前发现代码中的漏洞，将线上风险扼杀在摇篮中。写好单元测试是每一位程序员的基本功，但是有不少同学对于单元测试有些知其然但不知其所以然，对于单元测试的底层逻辑并未深入研究过，只停留在使用的层面。本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望能帮到每一位同学。
Java中存在很多单元测试框架，每种框架有着自己独特的特点，根据不同的需求和团队要求，每位同学所使用的框架不尽相同，目前主流的测试框架有且不仅有以下几种：
JUnit是Java中最常用的单元测试框架。该框架提供了丰富的测试与断言方法，例如：assertNull、assertTrue、assertEquals等，使用方法比较简单。JUnit目前已经更新到JUnit5版本，该版本提供了更多的新特性，例如：动态测试，依赖注入等，使得该框架更为健壮。
官网介绍：
https://junit.org/junit5/
TestNG是Java中的另一种测试框架，集团内使用的较为小众。该框架的设计是受了JUnit的启发，初衷是为了更好地支持从单元测试到集成测试的各个方面，用来完成一些JUnit所不能完成的测试任务。该框架较JUnit相比，功能更加强大，提供了更多的高级特性，例如：测试套件、数据驱动测试、依赖测试、并行测试等。在更复杂的测试场景（如参数化测试、依赖测试等）中，TestNG的表现更加优异。
官网介绍：
https://testng.org/
Spock是基于Groovy语言编写的测试框架，该框架可以用来测试Java和Groovy的代码程序。Spock用来写测试代码的语言十分优美、表达力强，这一优点大大提高了测试代码的可读性和可维护性。Spock框架融合了JUnit、jMock、RSpec、Groovy、Scala和Vulcans等多种框架和语言的优点，旨在提供一套强大的测试平台。
官网介绍：
https://spockframework.org/
Mockito不是一个完整的单元测试框架，而是专注于mock对象的创建、验证。它通常与JUnit或TestNG结合使用来简化对复杂依赖的测试。是目前集团内最主流的测试框架，下文中将对该框架进行详细阐述。
官网介绍：
http://site.mockito.org/
EasyMock是一套通过简单方法对于给定的接口生成mock对象的类库，通过使用Java代理机制动态生成模拟对象。该框架提供对接口的模拟，能够通过录制、回放、检查三步来完成大体的测试过程，可以验证方法的调用种类、次数、顺序等，还可以令mock对象返回指定的值或抛出指定异常。开发者通过EasyMock可以方便的构造mock对象而忽略对象背后真正的业务逻辑。一般情况下，EasyMock与JUnit或TestNG配合使用。
官网介绍：
https://easymock.org/
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是一种用于Java单元测试的框架，属于一种轻量级框架，该框架采用了行为驱动开发（BDD）的测试风格。用来在单元测试中mock接口或类的依赖项，对代码进行隔离测试，而无需关心整个系统的其他部分。JMock支持通过声明式的方式来指定对象间的交互行为。
官网介绍：
http://jmock.org/
大部分开发者在使用这些测试框架时，不会独立使用其中一种，而是会结合使用，例如，可以在JUnit或TestNG的基础上使用Mockito来创建和使用mock对象，来完成比较复杂的测试任务。每个框架都有其独特的优点与缺点，选择哪个框架通常取决于个人偏好、项目需求以及现有代码库的兼容性。
当然，实际开发中的单元测试框架远不止以上所提到的这些，还有一些同样优秀的框架在本文中没有介绍，例如：Selenium、Cucumber、Appium等，感兴趣的读者可以自行学习。
目前集团内主流的单元测试框架用的是Mockito框架，该框架的单元测试流程为：
@Autowired private BenefitRecordQueryServiceI benefitRecordQueryServiceI; @Override public List 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 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 res = new MultiResponse<>(); List 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 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个问题，那么这篇文章对于你来说是一个温故的作用；如果回答不上来，那么阅读这篇文章来知新吧！
@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的介绍，注入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) { Set mockFields = ...; Set injectMocksFields = ...; for (Field injectMocksField : injectMocksFields) { 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) { } } public class PropertySetterInjector { public void tryPropertyOrSetterInjection(Object fieldInstance, Field injectMocksField) { } }
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加载的对象有着明显的区别：
@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对象：
1.
调用createMockType方法，该方法基于提供的MockCreationSettings生成mock对象的类型；
2.
从Plugins中获取InstantiatorProvider的实例，然后调用getInstantiator方法获取Instantiator。
Instantiator是负责创建mock对象的组件；
3.
使用Instantiator的newInstance方法创建第一步生成的类型的新对象；
4.
创建MockMethodInterceptor拦截器对象，主要拦截对mock对象所进行的调用，并根据settings里的设置执行相应的逻辑；
5.
检查mock对象是否实现了MockAccess接口。
如果实现了，将mockMethodInterceptor设置为其拦截器；
至此，通过@Mock自动注入mock对象的主要过程就结束了，主要包括mock对象类型的确定、实例的创建、拦截器的设置以及异常的处理。可以看出，逻辑还是非常复杂的。下面通过一段伪代码对上述的流程进行逻辑概括：
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) { MockSettings mockSettings = configureMockSettings(mockAnnotation); return Mockito.mock(fieldType, mockSettings); } private static MockSettings configureMockSettings(Mock mockAnnotation) { MockSettings mockSettings = Mockito.withSettings(); if (!"".equals(mockAnnotation.name())) { mockSettings.name(mockAnnotation.name()); } if (mockAnnotation.stubOnly()) { mockSettings.stubOnly(); } mockSettings.defaultAnswer(mockAnnotation.answer()); return mockSettings; } public static T mock(Class classToMock, MockSettings mockSettings) { if (isNotMockable(classToMock)) { throw new MockitoException("Cannot mock/spy class: " + classToMock.getName()); } if (mockSettings == null) { mockSettings = withSettings(); T mockInstance = createMockInstance(classToMock, mockSetting return mockInstance; } private static
