spring中使用Mockito解决Bean依赖树问题方法-创新互联

前提

本文不是针对Mockito的入门教学 ，主要叙述如何简单的使用Mockito解决Bean依赖树问题，对于Mockito的学习请找其他的文章或者查阅官方文档

基本概念 Junit初始化及存在的问题

spring应用在unit test时，test是独立运行的，所以需要自行 init ApplicationContext，启动 Ioc容器。

Junit要求：Test类中涉及的所有Spring bean 注入成功才能完成applicationContext初始化，并启动IOC容器，否则无法执行unit test。

ApplicationContext初始化的两种方式 手动注入（使用 @Bean或者 @Component 注入所需的类）编写@Configuration 类（使用@ComponentScan 指定扫描beans） 两种初始化方式存在的问题

方式一：

所需的beans中，一个bean少注入了就会导致无法初始化上下文需要注入的bean太多时，需要花费大量的时间和精力，排查缺漏难度大

方式二：

颗粒度难以把控，随着项目规模变大之后，可能导致bean导入过多，单元测试跑很久才能通过当项目规模大了之后，bean之间的依赖往往是复杂的，扫描bean的方式可能出现一些不属于自己模块的未知问题或者某些中间件在unitTest环境无法正常启动，导致无法初始化上下文 什么是依赖树？

在开发应用时，往往会出现如上图的 树型依赖 ，比如 serviceA 调用 serviceB，serviceB 又调用 serviceC 。

然而这只是一个简单的例子。真正的开发中，往往一个 service 会依赖多个 service ，以及多个 dao ，以此来实现业务逻辑。

而根据Junit要求，我们必须将树的路径经过的所有节点(bean)都注入才能完成spring上下文初始化。这时如果bean之间的依赖耦合过大时，就无法跳脱出两种初始化方式带来的问题。

什么是Mockito？

在测试过程中，对于某些不容易构造（如 HttpServletRequest 必须在Servlet 容器中才能构造出来）或者不容易获取比较复杂的对象（如 JDBC 中的ResultSet 对象），用一个虚拟对象（Mock 对象）来创建以便测试的测试方法。

Mock 大的功能是帮你把单元测试的耦合分解开，如果你的代码对另一个类或者接口有依赖，它能够帮你模拟这些依赖，并帮你验证所调用的依赖的行为。

简单来说：就是虚拟一个mock对象，这个对象在单元测试时会“狸猫换太子”，将原有bean进行替换，“骗过”spring初始化，成功启动ioc容器，以此规避常规初始化方式带来的种种问题。

开发场景

结合本人在工作中遇见的问题，当时我所写的模块进行unitTest时，就出现了依赖树过于庞大的问题。

首先，我采用了常规的手动注入（方式一），导致注入了很久都没注入完，无法执行测试。后来觉得这方法在这种情况不可行。然后，我采用了编写@Configuration 类（方式二），同样也存在一些问题。一些不属于我负责模块的bean也被注入，其中某些涉及TaskSchedule的bean无法被正确注入，导致无法执行测试。此时一个个bean探索，解决问题显然不现实。最后，我采用Junit+Mockito结合的方式进行单元测试。按照依赖树大小进行区分。 依赖树小的直接使用常规的手动注入（方式一），省事，同时保证大部分逻辑按照代码正常运行依赖树大的使用Mockito，避免前文提到的两种初始化方式导致的问题

使用 1 导入maven依赖

首先导入mockito maven依赖,版本请根据自己的spring版本选择，否则会出现不兼容的情况。

      org.springframework.boot
      spring-boot-starter-test
      test
      
        
          org.junit.vintage
          junit-vintage-engine
        
      
    
    
      junit
      junit
      4.12
      test
    

另外有需要云服务器可以了解下创新互联建站www.cdcxhl.com，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。