如何在工程实践中利用“控制反转（IoC）”重构业务逻辑以支持零成本的单元测试 Mock

作者：袖梨 2026-07-19

直接 new 依赖导致测试无法 Mock，因为实例硬编码在类内，编译期绑定且运行时不可替换；必须通过构造函数注入接口依赖，才能在测试中传入 mock 对象。

为什么直接 new 依赖会导致测试无法 Mock

当你在业务类里写 new DatabaseService() 或 new HttpClient()，这个实例就硬编码在类内部了。单元测试时，你没法替换成 MockDatabaseService —— 它根本不是构造参数，也不是成员变量可替换的对象。编译期绑定 + 运行时不可控 = 测试只能走真实路径，要么失败，要么污染环境。

常见错误现象包括：NullPointerException（因为 mock 没注入）、Connection refused（测试连了真数据库）、断言永远通过或永远失败（因外部状态不可控）。

关键不是“能不能 mock”，而是“mock 的入口在哪”。IoC 的作用，就是把那个入口显式暴露出来。

用构造函数注入替代 new 实例是最稳妥的起点

构造函数注入让依赖关系一目了然，且天然支持测试时传入 mock 对象。它不依赖框架，纯语言机制，C++、Go、Java、Python 都适用。

把原来类内 private DatabaseService db = new DatabaseService(); 改成 private final DatabaseService db;
在构造函数中接收它：public UserService(DatabaseService db) { this.db = db; }
测试时直接传 mock：new UserService(mockDb)

注意：不要用 setter 注入代替构造注入，除非有循环依赖等极特殊情况。setter 允许对象处于不完整状态，容易漏设、难验证；而构造注入强制依赖存在，测试时也更易发现遗漏。

接口抽象是 Mock 可行性的前提，不是可选项

如果被注入的是具体类（比如 PostgreSQLService），那 mock 就得继承它 —— 但很多类是 final，或有复杂初始化逻辑，mock 成本高甚至不可行。真正能轻松 mock 的，只有接口或抽象类。

例如，在 Go 中定义：type PaymentGateway interface { Charge(amount float64) error }，测试时用 struct 实现该接口即可；在 C++ 中用纯虚类：class PaymentGateway { public: virtual ~PaymentGateway() = default; virtual bool charge(double amount) = 0; };

没有接口抽象，IoC 注入的就是具体实现，Mock 就退化为“重写私有方法”或“打桩系统调用”，既脆弱又难维护。