ASP.NET迁移.NET Core中Moq测试的IDependencyResolver使用问题

1. ASP.NET环境下，这是不是Moq测试依赖注入的正确方式？ #

不是。ASP.NET官方推荐的DI测试方式，应该直接通过构造注入给被测类传入依赖实例，或是通过正规DI容器注册后获取服务。Mock IDependencyResolver本身属于绕开正常DI流程的不规范写法，不符合依赖注入的设计原则。

2. 这段代码实际要实现什么？ #

这段代码的核心逻辑是：

• 创建IPizzaAvailibiltyMock和IPizzaClientOrchestrationMock的Moq实例
• 模拟ASP.NET全局的DependencyResolver，让系统中那些硬编码调用DependencyResolver.Current.GetService<T>()获取服务的代码，能拿到上面创建的Mock实例
• 本质是给依赖全局解析器的老旧代码提供测试用的依赖实例

移除代码后无明显错误的原因 #

移除后没出现问题，大概率是以下情况之一：

• 被测代码并没有通过DependencyResolver.Current获取这两个服务，而是用了构造注入或其他规范方式获取依赖
• 当前测试用例没有触发需要调用这两个Mock服务的业务逻辑
• 项目中其他地方已经初始化了相关依赖，覆盖了这段代码的作用

迁移到.NET Core的测试建议 #

由于.NET Core已废弃DependencyResolver，改用内置DI容器，测试时推荐两种方式：

1. 直接给被测类的构造函数传入Mock实例（最简洁可靠的构造注入测试方式）
2. 若需模拟完整DI容器，可通过IServiceCollection注册Mock服务后构建ServiceProvider，示例代码：

[TestInitialize]
public void Initialise()
{
    var services = new ServiceCollection();
    pizzaAvailibiltyMock = new Mock<IPizzaAvailibiltyMock>();
    pizzaClientOrchestrationMock = new Mock<IPizzaClientOrchestrationMock>();
    services.AddSingleton(pizzaAvailibiltyMock.Object);
    services.AddSingleton(pizzaClientOrchestrationMock.Object);
    var serviceProvider = services.BuildServiceProvider();
    // 从serviceProvider获取被测类实例，或直接将Mock传入被测类构造函数
}

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