从源码读懂Mockito 5.x架构：mockito-core核心组件与调用链路深度拆解

从源码读懂Mockito 5.x架构mockito-core核心组件与调用链路深度拆解【免费下载链接】mockitoMost popular Mocking framework for unit tests written in Java项目地址: https://gitcode.com/gh_mirrors/mo/mockitoMockito 是 Java 单元测试中最流行的 Mock 框架而mockito-core正是它的灵魂所在。本文带你从源码视角拆解 Mockito 5.x 的架构核心组件有哪些、它们如何分工、一次mock()/when()/verify()调用背后完整走了哪些链路帮助新手快速建立对 Mockito 内部机制的全景认知 一图看懂 mockito-core 的目录架构整个框架的源码位于 mockito-core/src/main/java/org/mockito/可以按职责分成几大块组件包职责代表类org/mockito/对外公开 APIMockito、ArgumentMatchers、Answersinternal/creation/Mock 对象创建字节码生成ByteBuddyMockMaker、MockSettingsImplinternal/handler/拦截并处理每次方法调用MockHandlerImplinternal/stubbing/桩定义stubbing存储与匹配InvocationContainerImplinternal/verification/调用验证verifyVerificationModeFactory、Timesinternal/progress/线程级进行中状态状态机MockingProgressImplinternal/matchers/参数匹配器实现Equals、InstanceOf、Findplugins/插件扩展点MockMaker、AnnotationEngine这个分层非常清晰公开 API 负责易用性internal 包负责核心逻辑plugins 包负责可替换性——Mockito 5.x 的大部分能力都建立在这三者的协作之上。mock() 调用链拆解一个 Mock 是如何诞生的以最常见的Mockito.mock(Service.class)为例调用链路如下入口Mockito.java 的mock()静态方法负责参数校验并把请求委托给内核。内核调度MockitoCore.java 的mock(Class, MockSettings)方法完成三件事用 MockSettingsImpl 把用户设置构造成内部创建配置MockCreationSettings检查DoNotMock注解是否违规调用MockUtil.createMock()真正生成对象。工厂方法MockUtil.java 的createMock()是关键枢纽——它先从插件注册表取出MockMaker创建MockHandler然后把两者交给MockMaker.createMock(settings, handler)。这就是谁创建 Mock、谁拦截调用两条职责线的交汇点。字节码生成默认实现 InlineByteBuddyMockMaker.javaMockito 5.x 默认 inline mock maker基于 ByteBuddy 生成字节码配合 ObjenesisInstantiator 免构造器实例化对象并通过MockMethodAdvice把每个方法调用重定向到 mock 的 handler 上。一句话总结API 层 → 内核调度 → 工厂装配 → MockMaker 生成字节码对象。调用处理核心MockHandlerImpl 的三分支决策Mock 对象每被调用一次都会进入 MockHandlerImpl.java 的handle(Invocation)方法。这里是整个框架最精华的路由器它按优先级做三次判断分支一doReturn/doThrow 风格打桩。若invocationContainer.hasAnswersForStubbing()为真说明用户走的是doReturn(x).when(mock).method()路径此时只记录要打桩哪个方法立即返回 null分支二verify 验证模式。从MockingProgress中取出当前验证模式非空说明处于verify()流程于是构造VerificationDataImpl交给验证器执行断言分支三常规打桩 / 返回值。把本次调用记为潜在打桩目标然后在桩容器里findAnswerFor(invocation)查找匹配答案命中则执行stubbing.answer(invocation)未命中则调用默认 Answer返回 null、0、空集合等让when()链能继续走下去。可以看到打桩、验证、返回值三路流量全部汇聚到这一个 handler这正是 Mockito 拦截一切设计的核心。幕后功臣MockingProgress 状态机MockingProgress 接口实现类 MockingProgressImpl.java管理着当前线程正在进行什么操作的共享状态包括正在进行的打桩reportOngoingStubbing()/pullOngoingStubbing()当前验证模式verificationStarted()/pullVerificationMode()参数匹配器栈ArgumentMatcherStorage——any()、eq()等匹配器先压栈等方法调用真正发生时再由 MatchersBinder 绑定到参数上。它是解释为什么 matcher 不能和普通参数混用为什么打桩要写在when(...)里这类经典问题的关键——答案都藏在状态机的时序约束中 插件体系Mockito 5.x 的扩展骨架plugins/ 目录定义了全套扩展点统一由 Plugins.java 门面类按classpath 约定 默认实现的策略装配MockMakerMock 生成器可在mockito-extensions/org.mockito.plugins.MockMaker文件中声明自定义实现甚至对单个 mock 用withSettings().mockMaker(...)指定AnnotationEngineMock/InjectMocks注解注入引擎InstantiatorProvider2、MemberAccessor、StackTraceCleanerProvider等。这种接口 classpath 文件约定的加载方式让 mockito-subclass、mockito-android 等周边模块无需改动核心代码即可替换实现是 Mockito 模块化拆分mockito-core / mockito-subclass / mockito-inline的根基。关键源码路径速查表想理解什么去看哪里公开 API 全集Mockito.java内核调度逻辑MockitoCore.java调用拦截与路由MockHandlerImpl.java桩存储与匹配InvocationContainerImpl.java验证模式工厂VerificationModeFactory.java时序状态机MockingProgressImpl.java插件加载门面Plugins.java行为验证测试MockitoTest.java写在最后Mockito 5.x 的架构可以浓缩为一句话MockMaker 负责造MockHandler 负责拦InvocationContainer 负责记VerificationMode 负责查而 MockingProgress 是串联四者的共享状态机。理解了这条主链路再去看 deep stubs、static mock、construction mock 等高级特性你会发现它们不过是同一套调用链路在不同入口的复用。建议新手按本文目录 → MockHandlerImpl 源码 → 跑一遍测试的顺序深入用不到一小时就能真正读懂 Mockito 的内部世界 【免费下载链接】mockitoMost popular Mocking framework for unit tests written in Java项目地址: https://gitcode.com/gh_mirrors/mo/mockito创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考