编写可测试的C++代码需通过依赖注入降低耦合，例如将NetworkUploader接口注入Logger类，使测试时可用MockUploader验证调用行为，结合Google Mock可精准控制依赖并验证逻辑，避免全局状态和单例以消除隐藏依赖，同时设计小而专注的类与接口，确保单一职责，提升模块化与可测性。
编写可测试的 C++ 代码，关键在于降低耦合、提升模块化，并通过依赖注入（Dependency Injection, DI）将外部依赖显式传递，而不是在类内部硬编码创建。这不仅让代码更清晰，也使得单元测试可以轻松替换真实依赖为模拟对象（mocks/stubs），从而独立验证逻辑。
使用依赖注入解耦组件
依赖注入的核心思想是：不主动创建依赖对象，而是由外部传入。这样可以在运行时使用真实服务，在测试时注入模拟实现。
例如，一个日志处理器依赖网络上传功能：
class NetworkUploader {
public:
virtual ~NetworkUploader() = default;
virtual bool upload(const std::string& data) = 0;
};
class RealUploader : public NetworkUploader {
public:
bool upload(const std::string& data) override {
// 实际网络请求
return true;
}
};
class Logger {
NetworkUploader uploader;
public:
explicit Logger(NetworkUploader up) : uploader(up) {}
void log(const std::string& message) {
if (uploader->upload(message)) {
std::cout << "Logged: " << message << std::endl;
}
}};
立即学习“C++免费学习笔记（深入）”；
在测试中，我们可以传入一个模拟的 MockUploader，验证是否调用了上传方法，而无需真正发请求。
配合 Google Test 和 Google Mock 进行单元测试
Google Mock 提供了强大的接口模拟能力。继续上面的例子：
#include#include class MockUploader : public NetworkUploader { public: MOCK_METHOD(bool, upload, (const std::string&), (override)); };
TEST(LoggerTest, CallsUploadOnLog) { MockUploader mockUploader; Logger logger(&mockUploader);
EXPECT_CALL(mockUploader, upload("test message")) .Times(1) .WillOnce(testing::Return(true)); logger.log("test message");}
这个测试验证了 log 方法确实调用了 upload，且参数正确。由于使用了依赖注入，我们完全控制了行为，避免了外部副作用。
避免全局状态和单例模式
全局变量和单例会破坏可测试性，因为它们引入隐藏依赖，难以重置状态。如果必须使用单例，考虑将其抽象为接口并通过 DI 使用。
错误示例：
class Logger {
public:
void log(const std::string& msg) {
SingletonDB::instance().save(msg); // 隐藏依赖
}
};
改进方式是将数据库访问抽象为接口并注入：
class Database {
public:
virtual ~Database() = default;
virtual void save(const std::string& data) = 0;
};
class Logger {
Database db;
public:
explicit Logger(Database db) : db(db) {}
void log(const std::string& msg) { db->save(msg); }
};
设计小而专注的类与接口
单一职责的类更容易测试。如果你发现某个类需要大量 mock 才能测试，说明它可能承担了太多责任。
建议：
- 每个类只做一件事
- 接口尽量小，只暴露必要的方法
- 优先使用组合而非继承来复用代码
这样的结构天然支持测试隔离，也便于维护和重构。
基本上就这些。只要坚持依赖注入、面向接口编程、避免隐藏依赖，C++ 的单元测试就会变得直接而可靠。工具链成熟（如 gtest + gmock），关键是设计习惯的转变。不复杂但容易忽略。
