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

直接 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 就退化为“重写私有方法”或“打桩系统调用”，既脆弱又难维护。

C++ 和 Go 中绕过框架也能做 IoC，但必须守住两个边界

很多人误以为 IoC 必须用 Spring 或 Autofac。其实只要满足两点：依赖由外部提供、调用方不负责创建，就已经是 IoC。C++ 和 Go 项目常因轻量级需求不引入容器，这时靠手动组装就能达成目标。

两个不能破的边界：

• 业务代码里禁止出现 new（除 DTO、value object 等无行为对象）：否则就回到了开头的问题
• 所有跨模块协作必须通过接口（或 protocol / abstract class）：否则 mock 无法替代，也无法静态检查契约一致性

一个容易被忽略的细节：C++ 模板类（如 std::vector）本身不是接口，不能被 mock。若业务逻辑强依赖某模板行为，应包装一层接口（如 StorageBackend），再注入它 —— 否则覆盖率工具会把模板实例算作“未覆盖”，实际却是测试根本没跑通路径。