Angular路由模块测试问题：Mock Resolver未生效及测试方案合理性咨询

问题1：Mock解析器未生效的原因及修复 #

你的MockAccountResolver没被使用，核心原因是DI系统没有正确替换掉原始的AccountResolver。路由配置里的resolve: { campaign: AccountResolver }明确指定了要注入AccountResolver类，所以你需要在测试模块的providers中显式用Mock类替换它，而不是同时提供两个或者只提供Mock类。

正确的测试模块配置 #

修改你的beforeEach中的providers配置，用useClass替换原始的AccountResolver：

@Injectable()
export class MockAccountResolver implements Resolve<Account> {
  resolve(): Observable<Account>{
    return of(new Account());
  }
}

beforeEach(() => {
  TestBed.configureTestingModule({
    imports: [RouterTestingModule.withRoutes(routes)],
    declarations: [AccountDetailComponent],
    // 关键：用Mock类替换原始的AccountResolver
    providers: [
      { provide: AccountResolver, useClass: MockAccountResolver }
    ]
  });
  router = TestBed.inject(Router); // Angular 9+推荐用inject替代get，更规范
  location = TestBed.inject(Location);
  router.initialNavigation();
});

额外注意事项：

• 不要在测试模块中导入原始的AccountRoutingModule或AccountModule，否则原始的AccountResolver会被DI系统优先注入，覆盖你的Mock。
• 如果AccountDetailComponent还有其他依赖（比如组件内用到的服务），也需要Mock这些依赖，避免组件初始化时报错。

错误配置的原因解析 #

你之前尝试的两种providers配置都存在问题：

1. providers: [ AccountResolver, MockAccountResolver]：同时提供两个解析器时，DI系统会优先使用原始的AccountResolver，所以依然会触发它的依赖（ApiService）。
2. { provide: AccountResolver, useValue: new MockAccountResolver()}：写法本身没问题，但如果Mock类后续新增依赖，手动实例化会导致DI异常，用useClass更稳妥。

问题2：测试方案的合理性 #

你的测试方案非常合理，甚至是推荐的最佳实践。

为什么你的方案优于复制配置 #

多数示例中直接在测试里写路由配置，只是为了简化演示，但这种方式的致命缺陷是：当实际路由模块的配置变更时（比如路径修改、新增/删除路由、resolve规则变更），测试代码里的复制配置不会同步更新，导致测试用例与实际代码脱节，无法检测到破坏性变更。

而你直接从路由模块导出routes并在测试中使用，能保证测试用的路由配置与生产环境完全一致，一旦实际路由出现破坏性变更，测试会立刻失败，及时发现问题，完全符合测试保障代码变更安全性的核心目的。

补充优化建议 #

为了让测试更健壮，你还可以：

• 测试路由守卫、解析器的逻辑（比如验证解析器是否被调用，返回的数据是否符合预期）。
• 对懒加载模块的路由，测试其加载逻辑是否正常（可以结合RouterTestingModule.withRoutes和loadChildren的Mock实现）。

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