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

一分耕耘，一分收获！既然都打开这篇《如何利用“依赖注入”模式在单元测试时轻松替换掉真实的后台请求模块》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新文章相关的内容，希望对大家都有所帮助！

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

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

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

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

• iOS（Swift）：声明 protocol NetworkService { func fetchData(completion: @escaping (Result) -> 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 和传参的事。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。