在单元测试中使用内置Microsoft DI初始化对象是否可行？是否为最佳实践？

1. 能否在单元测试中使用内置Microsoft DI初始化对象？ #

当然可以。借助Microsoft.Extensions.DependencyInjection包，你可以在单元测试项目中搭建专属的DI容器，注册所需服务后直接获取对象实例。

举个简单的实现示例：

// 先确保安装了Microsoft.Extensions.DependencyInjection NuGet包
var serviceCollection = new ServiceCollection();

// 注册依赖：可以是Mock对象，也可以是无外部副作用的真实实现
serviceCollection.AddTransient<IMyDependency, MockedMyDependency>();
serviceCollection.AddTransient<MyTargetClass>(); // 待测试的类，依赖IMyDependency

// 构建服务提供者并获取目标实例
using var serviceProvider = serviceCollection.BuildServiceProvider();
var targetInstance = serviceProvider.GetRequiredService<MyTargetClass>();

// 后续即可对targetInstance执行单元测试逻辑

2. 这是不是单元测试的良好实践？ #

答案是分场景而定，核心要紧扣单元测试的本质：隔离依赖、聚焦单一功能、快速稳定执行。

不推荐的场景 #

• 注入真实外部依赖：如果用DI注入数据库访问、第三方API调用等真实服务实现，你的测试会绑定外部资源（比如数据库、网络），这已经不属于单元测试范畴，而是集成测试。这类测试运行慢、易受环境影响，完全违背了单元测试的隔离要求。
• 为省事儿过度依赖DI：如果只是为了省去手动构造对象的步骤就引入DI，反而会让测试代码复杂化——你需要额外维护DI配置，排查问题时还要验证容器注册是否正确，无端增加了测试的心智负担。

可以接受的场景 #

• 待测试类依赖过多，手动构造繁琐：如果目标类有5个以上的依赖，且所有依赖都已被Mock/Stub（无外部副作用），用DI容器批量注册Mock并实例化对象，能有效减少重复代码。
• 验证DI配置的正确性：比如测试生产环境的DI注册逻辑是否能正确创建对象，但这类测试更偏向集成测试范畴，不属于纯单元测试。

总结 #

单元测试的优先选择是手动构造实例+直接注入Mock依赖（比如用Moq等框架创建Mock对象），这样测试代码更简洁直观，也能精准控制每个依赖的行为。只有在特定复杂场景下，才考虑用DI辅助实例化，但务必确保所有依赖都是隔离的Mock/Stub，避免引入外部资源。

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