@nestjs/testing的Test.createTestingModule不支持forwardRef问题求助

核心思路 #

要在集成测试中保留真实业务依赖、同时绕过Test.createTestingModule对forwardRef的支持限制，核心是让测试模块正确识别并处理循环依赖的注入逻辑，无需修改原有业务代码。

可行方案 #

方案1：测试模块内显式声明forwardRef依赖 #

在createTestingModule的providers配置中，针对存在循环依赖的服务，手动用工厂函数结合forwardRef声明注入关系，示例：

const moduleFixture = await Test.createTestingModule({
  providers: [
    ServiceA,
    {
      provide: ServiceB,
      useFactory: (serviceA: ServiceA) => new ServiceB(serviceA),
      inject: [forwardRef(() => ServiceA)],
    },
  ],
}).compile();

这种方式完全基于测试代码调整，不改动业务逻辑，通过显式的工厂函数注入解决循环引用问题。

方案2：复用应用根模块的依赖配置 #

如果你的应用根模块已经通过forwardRef正确处理了循环依赖，直接在测试中导入根模块即可，仅按需替换外部依赖（如第三方服务）：

const moduleFixture = await Test.createTestingModule({
  imports: [AppModule],
})
// 仅替换需要模拟的外部服务，保留内部真实依赖
.overrideProvider(ExternalApiService)
.useValue(mockExternalApiService)
.compile();

此方案直接复用业务代码中已验证的forwardRef配置，无需在测试中重复处理循环依赖，是最省心的过渡方案。

方案3：封装通用测试模块工厂函数 #

如果多个测试场景都需要处理类似循环依赖，可以封装一个辅助函数统一处理forwardRef的注入逻辑，避免重复代码：

export function createTestingModuleWithForwardRef(metadata: TestingModuleMetadata) {
  const processedProviders = metadata.providers?.map(provider => {
    // 简易判断：检查服务是否有forwardRef标记的依赖
    if (typeof provider === 'function' && provider['forwardRefDeps']) {
      return {
        provide: provider,
        useFactory: (...args) => new provider(...args),
        inject: provider['forwardRefDeps'].map(dep => 
          typeof dep === 'function' && dep.name === 'forwardRef' ? dep() : dep
        ),
      };
    }
    return provider;
  });

  return Test.createTestingModule({
    ...metadata,
    providers: processedProviders,
  });
}

这里的forwardRefDeps需要你在业务服务上添加一个自定义标记（比如静态属性），标识哪些依赖需要用forwardRef处理。辅助函数只需编写一次，后续测试直接调用即可。

注意事项 #

• 集成测试中保留真实依赖时，需确保业务代码的循环依赖逻辑本身是合法的，避免将业务bug误认为测试模块问题。
• 上述方案均为过渡性解决手段，长期来看仍建议逐步优化业务代码的依赖结构，减少循环依赖。

内容的提问来源于stack exchange，提问作者Victor Shelepen