您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
一文详解单元测试干了什么
 
作者: 离澈
  319  次浏览      7 次
 2024-3-8
 
编辑推荐:
本文从常用的单元测试框架出发,对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框架运行单元测试的常用底层逻辑,对其中的一些高级特性并未深入探讨,感兴趣的小伙伴可以自行研究。单元测试是开发中一个庞大的分支,并非一篇文章能论述得清楚。当然,如果此文能引起你对单元测试底层逻辑的兴趣,那便是本文最大的价值了。

 

 

   
319 次浏览       7
相关文章

微服务测试之单元测试
一篇图文带你了解白盒测试用例设计方法
全面的质量保障体系之回归测试策略
人工智能自动化测试探索
相关文档

自动化接口测试实践之路
jenkins持续集成测试
性能测试诊断分析与优化
性能测试实例
相关课程

持续集成测试最佳实践
自动化测试体系建设与最佳实践
测试架构的构建与应用实践
DevOps时代的测试技术与最佳实践

最新活动计划
UAF架构体系与实践 5-17[北京]
用户体验与界面设计 5-22[北京]
MBSE(基于模型的系统工程)6-20[北京]
大模型微调原理与实操 6-20[厦门]
图数据库与知识图谱 6-27[北京]
Linux内核编程及设备驱动 7-25[北京]
 
 
最新文章
大数据平台测试
微服务架构下的测试之道
从零开始掌握微服务软件测试
如何进行测试需求分析:从接收需求到用例设计
python_selenium自动化测试框架
最新课程
测试需求分析与测试用例设计
性能测试方法与技术
自动化测试框架设计高级实践
接口自动化测试方法与工具
软件测试方法与实践(贯穿案例)
更多...   
成功案例
某支付企业 单元测试与重构培训
北京 用户体验、可用性测试与评估
某军工研究单位 自动化测试方法、案例与工具
知名消费金融公司 探索性测试与测试分析
北京 航天科工某子公司 软件测试架构师
更多...