如何利用依赖注入模式在单元测试时轻松替换掉真实的后台请求模块

核心思路是通过接口抽象和构造函数注入实现网络请求的可替换性，业务类依赖NetworkService等抽象接口而非具体实现，测试时传入Mock或Stub对象控制返回数据，确保测试快速稳定可重复。

核心思路是让被测代码不自己创建网络请求对象，而是由外部把“能发请求的东西”交进来——这样测试时就能换成一个假的、可控的版本。

让请求逻辑变成可替换的接口

不要在业务类里直接 new Retrofit 或 URLSession。先定义一个协议或接口，比如：

• iOS（Swift）：声明 protocol NetworkService { func fetchData(completion: @escaping (Result<Data, Error>) -> Void) }
• Android（Kotlin）：定义 interface ApiService { suspend fun getUser(id: Long): User }
• C# / Java：用 IHttpService 或 ApiRepository 这样的抽象类型，不写具体实现

业务类只依赖这个接口，不关心谁来实现它。

通过构造函数注入，切断硬编码依赖

把网络服务作为参数传进类里，而不是在内部创建：

• 比如 class UserManager(private val api: NetworkService)
• 测试时直接传入一个伪造对象：UserManager(mockNetworkService)
• 真实运行时才传入 RetrofitNetworkService() 或 AlamofireService()

这种方式不需要改业务代码加 setter，也不用动静态方法，干净且符合单一职责原则。

测试中用 Mock 或 Stub 替换真实请求

不调用真实服务器，而是控制返回数据和行为：

• 用 Mockito（Java/Kotlin） 或 NSubstitute（C#） 创建接口的模拟实例
• 用 Swift 的协议扩展 + 空实现 写一个轻量 Stub，比如返回固定 JSON 或抛出特定错误
• 验证关键行为：比如检查 api.fetchData() 是否被调用了一次，或是否传了正确的参数

这样测试就快、稳、可重复，也不怕网络抖动或后端未就绪。

框架辅助（可选但推荐）

如果项目已有 DI 容器（如 Dagger、SimpleInjector、Objection、Spring Boot 的 @MockBean），可以利用它统一管理替换逻辑：

• 测试配置中注册 mock 实例，覆盖默认的网络 service Bean
• 避免每个测试都手动构造整条依赖链
• 保持测试环境与运行环境结构一致，降低遗漏风险

没用框架也完全可行——只要坚持接口抽象 + 构造注入，替换就只是几行 new 和传参的事。