教育单元测试mock框架优化之路（下）

转载：https://sq.163yun.com/blog/article/169563599967031296

四、循环依赖的解决

果然！

当我将@SpyBean应用到存在有循环依赖的Bean上时，会导致如下异常：

Bean with name userCouponService has been injected into other beans [bizOrderService,userCoupon

TemplateService] in its raw version as part of a circular reference, but has eventually been wrapped.

This means that said other beans do not use the final version of the bean. This is often the result

of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag

turned off, for example.

是的，相信英语好的同学们都已经看懂了。大致的意思是说，一部分依赖其的bean持有了其原始版本的引用（后面大家会发现其实是earlyBeanReference），而其又最终被进一步包装代理了，这样导致了后期再依赖其的beans中持有的引用与之前的不是同一个对象。所以，spring默认是禁止了这种情况的发生。（偷偷的说，其实spring内部有个开关，打开后容器将对这种不一致情况睁一只眼闭一只眼......不知道spring的本意如何。不过，掩耳盗铃对我们而言是没有意义的。）

那么，这个问题该怎么解决呢？

不幸的是，网上关于这个方面的文章很少。我也问过一些资深的同事，得的反馈是这个问题的确没有特别好的解决办法。建议从业务上，尽量避免循环依赖，或通过lazy-init来解决。但现实的开发工作中，由于业务复杂、开发人员编码水平参差不齐、遗留系统等原因，循环依赖往往难以真正避免。而lazy-init也不是万能药，很有可能在某个时候就被某一个非lazy bean在初始化阶段引入调用而遭到破坏。那么，如果框架可以解决，还是尽量从框架层面本身去解决吧。

仔细想想，有一点很值得怀疑。那就是为什么在我们增加@SpyBean前，循环依赖是照样可以正常工作的，加上就不行了呢？是不是springboot test框架在做mock（spy）对象的注入时存在缺陷呢？

追踪下userCouponService bean的整个生命周期，终于找到了问题的根源。原来是springboot test框架的SpyPostProcessor在处理bean wrapping时存在缺陷，它没有考虑循环依赖的场景。

同样都是SmartInstantiationAwareBeanPostProcessor，spring自家的AbstractAutoProxyCreator在做代理时就会考虑这个循环依赖的处理细节。让我们先看下AbstractAutoProxyCreator相关源码：

@Override
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
   Object cacheKey = getCacheKey(bean.getClass(), beanName);
   if (!this.earlyProxyReferences.contains(cacheKey)) {
      this.earlyProxyReferences.add(cacheKey);
   }
   return wrapIfNecessary(bean, beanName, cacheKey);
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
   if (bean != null) {
      Object cacheKey = getCacheKey(bean.getClass(), beanName);
      if (!this.earlyProxyReferences.contains(cacheKey)) {
         return wrapIfNecessary(bean, beanName, cacheKey);
      }
   }
   return bean;
}

然后，我们再对比下SpyPostProcessor的相关源码：

@Override
public Object getEarlyBeanReference(Object bean, String beanName)
      throws BeansException {
   return createSpyIfNecessary(bean, beanName);
}

@Override
public Object postProcessAfterInitialization(Object bean, String beanName)
      throws BeansException {
   if (bean instanceof FactoryBean) {
      return bean;
   }
   return createSpyIfNecessary(bean, beanName);
}

相信大家已经发现，SpyPostProcessor在处理上偷工减料了。合理的姿势应该是：如果一个Bean在earlyInit的阶段(getEarlyBeanReference)，就生成了代理对象并交付到spring内部的集合中后，postProcessAfterInitialization阶段就不要再对bean对代理处理。因为spring的AbstractAutowireCapableBeanFactory在doCreateBean中，已经做了如下处理（注意我红色标记的部分）：

// Initialize the bean instance.
Object exposedObject = bean;
try {
   populateBean(beanName, mbd, instanceWrapper);
   if (exposedObject != null) {
       //看这里，如果没有限制，SpyPostProcessor.postProcessAfterInitialization会在initializeBean方法里面搞事情，导致输出的exposedObject为
       //原exposedObject的代理对象。
       exposedObject = initializeBean(beanName, exposedObject, mbd);
   }
}
catch (Throwable ex) {
   if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
      throw (BeanCreationException) ex;
   }
   else {
      throw new BeanCreationException(
            mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
   }
}

if (earlySingletonExposure) {
   Object earlySingletonReference = getSingleton(beanName, false);
   if (earlySingletonReference != null) {
      //看这里。如上，一旦exposedObject被bean的spy代理，这个if分支就不成立，而走向异常检测的深渊。而我再前面也讲过，这实际上并不是为检测而检测，因为
      //它事实在破坏不同依赖bean包含当前bean引用的一致性。
      if (exposedObject == bean) {
         //再看这里。如果按照spring预设的方案，对于循环依赖的bean，都统一在getEarlyBeanReference阶段完成代理并投放到内部的earlySingletonObjects
         //容器。那么这段赋值逻辑，就能保证最终暴露出来的singleton（即交付到内部的SingletonObjects集合）的bean等同于earlySingletonReference。这样，
         //就能确保其他所有bean都依赖同一个当前bean的引用。
         exposedObject = earlySingletonReference;
      }
      else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
         //下面就是导致本章开始那段异常的校验逻辑
         String[] dependentBeans = getDependentBeans(beanName);
         Set actualDependentBeans = new LinkedHashSet(dependentBeans.length);
         for (String dependentBean : dependentBeans) {
            if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
               actualDependentBeans.add(dependentBean);
            }
         }
         if (!actualDependentBeans.isEmpty()) {
            throw new BeanCurrentlyInCreationException(beanName,
                  "Bean with name '" + beanName + "' has been injected into other beans [" +
                  StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
                  "] in its raw version as part of a circular reference, but has eventually been " +
                  "wrapped. This means that said other beans do not use the final version of the " +
                  "bean. This is often the result of over-eager type matching - consider using " +
                  "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
         }
      }
   }
}

既然问题已然明了，那解决办法也就简单了。我要做的就是扩展实现SpyPostProcessor，然后引入相似的单例检测，循环依赖导致的异常问题解决了！~让我们具体看下EduSpyPostProcessor的实现：

@Override
public Object getEarlyBeanReference(Object bean, String beanName)
        throws BeansException {

    Object cacheKey = getCacheKey(bean.getClass(), beanName);
    if (!this.earlyProxyReferences.contains(cacheKey)) {
        this.earlyProxyReferences.add(cacheKey);
    }
    return createSpyIfNecessary(bean, beanName);
}

@Override
public Object postProcessAfterInitialization(Object bean, String beanName)
        throws BeansException {
    if (bean == null) {
        return bean;
    }
    if (bean instanceof FactoryBean) {
        return bean;
    }

    Object cacheKey = getCacheKey(bean.getClass(), beanName);
    if (!this.earlyProxyReferences.contains(cacheKey)) {
        return createSpyIfNecessary(bean, beanName);
    }

    return bean;
}

总结：

至此，我们的单元测试mock框架算告了一小个段落。我们可以：

1. 通过@EduMock,@EduSpy,@EduInjectMocks实现单层的属性的mock替换，同时解决了待InjectMocks bean为动态代理对象的情况。

2. 通过@AutoMock+具体MockFactoryBean的方式，实现对类似于Dubbo等通用组件的自动Mock替换。

3. 通过@EduMockBean和@EduSpyBean的方式，基于IOC实现bean的嵌套属性的mock替换。

不过，我们仍有一个重要关卡要过。那就是对静态、私有、final、jdk内置等方法的mock支持。可喜的是，这个方面，PowerMockito框架已经做了支持。但如何和Spring容器，以及现有的Mock注入、状态重置、管理等框架集成，还有待进一步调研和验证。毕竟springboot test框架发展到现在，也只做了mockito框架的集成，总该有些原因吧。

路漫漫其修远兮，再慢慢求索吧！~