从给一个“下载器”类写单元测试开始说起吧。这类类对象往往依赖网络库、磁盘读写、甚至是系统时间，如果你真的在单测里发起HTTP请求，那测试就变成了“原谅我不厚道地笑了”现场——CI不稳定、跑得慢、失败了还不知道是代码错了还是网络抽风。这个场景正是C++类对象单元测试中Mock最典型的需求来源：把外部依赖替换成可控的替身，让被测类只面对逻辑本身。
这篇文章面向的是已经写过基础C++代码、会用Google Test或者至少能搭起一个测试工程的开发者，目标是帮你把Mock用得真正顺手，不是背语法，而是搞懂它解决的核心问题是什么、应该怎么设计代码来配合Mock、以及遇到“跑了半天EXPECT_CALL就是不生效”这种问题时该从哪里入手排查。全文都会围绕类对象单测这个主题展开，代码重点放在gMock上，毕竟这套组合在C++生态里用得最多、资料也最好找。
1. 类对象单元测试为什么绕不开Mock
1.1 你写单测时真正遇到的障碍是什么
很多人第一次给类写单元测试，写了一个测试函数，调用被测类的方法，然后断言返回值。写着写着就开始别扭了：被测类里new了一个数据库连接对象、构造时发了个网络请求、某个成员函数调用了系统时间函数、或者内部持有另一个业务类的实例，这个实例又依赖一堆复杂初始化条件。
这时候你会发现，明明是在“单元”测试，结果测着测着变成了“集成”测试。数据库连不上、外网不可用于是、接口返回数据变了，你的测试就废了。问题的本质不在于测试代码写得不对，而在于被测类对象和外部世界耦合得太紧。
从设计角度说，C++类的成员函数如果直接调用具体依赖类的实例，或者直接调用平台API，那这个类在测试环境里就没办法剥离外部因素。Mock解决的核心痛点就是这种耦合：它不改变被测类的代码，而是通过一个可替换的“替身对象”把外部依赖隔离掉，让被测类只能和替身交互，你则完全控制这个替身的行为。
1.2 Mock、Stub和Fake的区别必须搞清楚
很多人把Mock和Stub混着说，其实它们有明确分工。
Stub是“测试替身”的一种，它只负责返回预先设定好的数据，不关心自己“被没被调用”。比如你测一个类，它内部有个方法用来读配置，你用Stub返回固定配置，就算测试过程中这个方法一次都没被调用，测试也能通过，因为Stub不会去记录调用信息。Fake更接近一个简化版真实实现，比如测试内存数据库来代替真实数据库，它有真实逻辑，只是更轻量。而Mock核心特征在于“行为验证”：它不仅提供替代返回值，还会记录“某个方法有没有被调用、以什么参数调用、调用了几次”，如果实际调用方式和预期不一致，Mock会直接让测试失败。
放到C++类对象场景里，这意味着Mock适合验证的是“某个对象和另一个对象的交互是否正确”，而不仅仅是“计算结果是否正确”。比如一个订单服务类内部依赖一个支付网关类，你去断言订单服务返回的结果，并不能真正确认它有没有向支付网关发送正确的订单金额和回调地址，用Mock就能精确验证这类交互行为。
1.3 什么场景必须用Mock，什么场景别硬用
不是所有单元测试都需要Mock。我见过一些同学，为了显得专业，连一个简单计算器类都非要把加法和减法Mock掉，这纯属自找麻烦。
适合用Mock的典型场景是这些：
- 被测类依赖网络通信、数据库访问、消息队列、文件系统等外部资源
- 被测类依赖另一个不由你控制的第三方SDK，这个SDK在测试环境下很难初始化或很难稳定复现返回值
- 被测类依赖系统时间、随机数、线程调度等不定因素
- 被测类与另一个复杂业务类协作，你只关心当前类的逻辑，不想把整个链路都跑起来
不适合用Mock的情况也很明显：
- 被测对象本身是纯逻辑、纯算法类，直接用真实对象测试最简单的
- 被测对象是简单的实体类/POJO类，就是存一些字段、提供getter/setter，Mock这种类毫无意义
- 数据结构的容器类，比如自己封装了一个队列、栈，真实操作和断言即可
类对象单测里最常见的错误就是“过度Mock”，把被测类自己的内部方法也Mock了，结果测了个寂寞。记住一条原则：Mock是用来替换“依赖”的，不是用来替换“被测对象自身逻辑”的。
2. Mock工具选型与基础用法：以Google Mock为例
2.1 为什么选gMock而不是手动写桩类
C++生态里做Mock，目前主流方案就是Google Mock（gMock）。它是Google Test配套的Mock库，你的工程已经在用Google Test，那直接用gMock是最省事的，不需要额外引入第二个测试框架，CMake集成也简单。
市面上也有其他选择，比如HippoMocks、Trompeloeil、FakeIt，各有特点，但gMock的社区资料最齐全，出了坑一搜就有答案。更重要的是，gMock提供了一套比较完整的“行为设定 + 调用验证”机制：EXPECT_CALL设定预期，WillOnce/WillRepeatedly确定返回值，匹配器（Matcher）用来做参数匹配，还有NiceMock/StrictMock这种“性格”设置。
如果你尝试自己写桩类，比如手动定义一个假的HTTPClient类，写上几个方法的空实现，返回固定数据，那很快会面临一个问题：你发现每个需要测试的类都要手写一个假类，不同测试对返回值的要求还不一样，假类越写越大，最后变成了一个粗糙模拟系统，测试代码比业务代码还难维护。gMock的价值就在于把这些通用机制都做好了，你只需要描述“这个方法应该怎么被调用、被调用后返回什么”。
2.2 从一个最小可运行示例开始
先看一个非常典型的类对象单测场景：一个Downloader类，通过构造函数接收一个HttpClient对象，Downloader调用HttpClient的Get方法来下载文件内容。如果用真实HttpClient，每次单测都要联网，所以我们Mock掉HttpClient。
先定义接口和被测类：
// http_client.h #pragma once #include <string> class HttpClient { public: virtual ~HttpClient() = default; virtual std::string Get(const std::string& url) = 0; virtual int GetStatusCode(const std::string& url) = 0; };// downloader.h #pragma once #include <string> #include "http_client.h" class Downloader { public: explicit Downloader(HttpClient* client) : client_(client) {} bool Download(const std::string& url, std::string* content) { int status = client_->GetStatusCode(url); if (status != 200) { return false; } *content = client_->Get(url); return !content->empty(); } private: HttpClient* client_; };现在写测试。gMock要求通过宏来声明Mock类：
// mock_http_client.h #pragma once #include "http_client.h" #include "gmock/gmock.h" class MockHttpClient : public HttpClient { public: MOCK_METHOD(std::string, Get, (const std::string& url), (override)); MOCK_METHOD(int, GetStatusCode, (const std::string& url), (override)); };测试里这样用：
#include <gtest/gtest.h> #include <gmock/gmock.h> #include "mock_http_client.h" #include "downloader.h" using ::testing::Return; using ::testing::_; TEST(DownloaderTest, DownloadSuccessWhenStatusCodeIs200) { MockHttpClient mock_client; Downloader downloader(&mock_client); EXPECT_CALL(mock_client, GetStatusCode(_)).WillOnce(Return(200)); EXPECT_CALL(mock_client, Get(_)).WillOnce(Return("<html>ok</html>")); std::string content; bool result = downloader.Download("http://example.com", &content); EXPECT_TRUE(result); EXPECT_EQ(content, "<html>ok</html>"); }这段代码看着简单，但实际上把gMock几个核心概念都带出来了：MOCK_METHOD申明Mock方法，EXPECT_CALL设置预期调用次数和返回值，_是一个通配匹配器，表示“任何参数都行”。
2.3 核心语法逐层拆解：MOCK_METHOD、EXPECT_CALL和匹配器
MOCK_METHOD的语法如下，这是新版写法，老版本是MOCK_METHOD1这种带数字的写法，新版统一不同参数数量，好记多了：
MOCK_METHOD(返回类型, 方法名, (参数列表), (限定符列表));第四个参数里写的override表示这个Mock方法覆写了基类的虚函数，如果是const成员函数就要写成(const, override)。还有noexcept、ref等限定符可以在这里加。关键是：Mock方法必须和基类虚函数的签名完全一致，否则编译期可能报错或者行为不符合预期。
EXPECT_CALL是一条完整语句，它分三个部分：
- 第一部分指定Mock对象和方法，比如mock_client, GetStatusCode
- 第二部分是参数匹配器列表，比如(::testing::_)、(::testing::Eq("http://example.com"))，用来限定“这个方法被调用时必须使用什么参数”
- 第三部分是行为设置，比如WillOnce(Return(200))表示第一次调用返回200，WillRepeatedly(Return(0))表示之后任意次调用都返回0
除了指定返回值的Return，还常用SetArgReferee用来修改引用参数的值、ThrowException抛异常、Invoke调用自定义函数等。参数匹配器里最常用的我整理成一张表：
| 匹配器 | 含义 | 示例 |
|---|---|---|
_ | 匹配任何参数 | EXPECT_CALL(obj, Foo(_)) |
Eq(x) | 参数等于x | EXPECT_CALL(obj, Foo(Eq(42))) |
Ne(x) | 参数不等于x | EXPECT_CALL(obj, Foo(Ne(0))) |
Gt/Ge/Lt/Le(x) | 大于/大于等于/小于/小于等于x | EXPECT_CALL(obj, Foo(Gt(0))) |
AllOf(m1, m2) | 参数同时满足m1和m2 | EXPECT_CALL(obj, Foo(AllOf(Gt(0), Le(100)))) |
AnyOf(m1, m2) | 参数满足m1或m2 | EXPECT_CALL(obj, Foo(AnyOf(Eq("a"), Eq("b")))) |
HasSubstr(s) | 字符串包含子串s | EXPECT_CALL(obj, Foo(HasSubstr("error"))) |
实际用的时候，最常见的是“_加返回值”组合，因为很多情况下测试只关心“有没有调用”，不关心具体参数值。但如果你想验证“某个对象收到的是不是正确构造的参数”，那就必须用具体匹配器。比如订单类测试里，你希望验证Mock支付网关的charge方法被调用时传入的金额是100，那就写成EXPECT_CALL(mock_pay, charge(Eq(100), _))，这样能抓出“业务代码把金额传错”的隐性bug。
2.4 NiceMock、StrictMock和NaggyMock该怎么选
gMock对Mock对象调用了一个“没被EXPECT_CALL”的方法时，默认行为是输出一个警告，但不会导致测试失败。这类Mock对象叫NaggyMock，它其实是默认的“性格”。另外两个是NiceMock和StrictMock。
- NiceMock：调用未设置预期的方法时完全安静，不输出警告也不失败
- StrictMock：调用未设置预期的方法时直接让测试失败
- NaggyMock：输出警告，但不失败，就是默认行为
看起来StrictMock最严格，是不是应该全用这个？我个人在实际项目里的建议是：默认用NaggyMock，只在特定测试文件里用NiceMock和StrictMock。理由很简单：StrictMock一旦遇到未预期的合法调用就直接失败，这在大型类上会很痛苦，因为你可能只关注当前测试路径上的一两个方法，其他方法碰巧也被调用了，全都失败，很容易把真正要验证的错误淹没在报错里。NiceMock适合那种“我知道这个类依赖比较多，但本次测试只关心其中一条路径”的情况，其他调用就让它安静。当你真正需要严格约束交互，验证“这个对象不应该调用某个方法”时，再上StrictMock也不迟。
写测试代码时，我的经验是“先宽松后收紧”：调试阶段用NiceMock，让测试先跑通，确认逻辑正确后再把Mock换回默认行为甚至StrictMock，做到最终测试对一个测试点相关的交互有明确约束。
3. 改造代码才能Mock：可测试性设计与依赖注入实战
3.1 一个好设计是Mock的前提
写Mock最怕遇到一种情况：被测类的依赖对象根本没办法替换。比如被测类里直接new了一个具体对象：
class OrderService { public: bool CreateOrder(const OrderData& data) { PaymentGateway gateway; // 硬编码依赖 return gateway.Charge(data.payment, data.amount); } };你这个测试怎么写？PaymentGateway是具体类，没有virtual接口，gMock根本没法生成Mock对象。就算PaymentGateway本身有一些虚方法，你Mock了它，也没办法塞进OrderService里，因为OrderService内部自己new了一个。
这种代码被称为“不可测试性代码”，它不是写错，而是根本没有为测试预留替换点。想让Mock发挥价值，就必须先做可测试性设计改造。类对象环境中，最核心的手段就是面向接口编程和依赖注入。
3.2 依赖注入的三种常见姿势对比
依赖注入的目标很明确：让“依赖对象”从外部传入，而不是在被测类内部创建。
第一种是构造函数注入：
class OrderService { public: explicit OrderService(PaymentGateway* gateway) : gateway_(gateway) {} private: PaymentGateway* gateway_; };这种方式在类创建时就固定了依赖，生命周期清晰，是最推荐的方案。如果依赖是可空的话需要注意判空，但多数时候我们保证传入非空指针。
第二种是setter注入：
class OrderService { public: void SetPaymentGateway(PaymentGateway* gateway) { gateway_ = gateway; } private: PaymentGateway* gateway_ = nullptr; };这种方式灵活，测试时只在需要时设置依赖，但缺点是无法保证所有依赖都被设置，一旦漏设，运行时可能收到空指针。设置逻辑分散也让人的记忆负担变重。
第三种是工厂函数注入，也就是在被测类内部通过一个工厂函数创建依赖对象，测试时把工厂函数replace掉。这种方式适合对象的创建本身有复杂逻辑的场景，比较重，一般用不上。
就C++类对象单测而言，我强烈推荐构造函数注入作为默认方案。它最直白、最不容易出错，而且配合默认参数还能保持现有调用方代码不变。
3.3 实战改造：从不可测到可测的完整过程
看一个更实际的例子。你有这样一个用户数据同步类，它直接调用了外部SDK：
// 原始代码 class UserSync { public: bool Sync(UserInfo user) { CloudSyncSDK sdk; sdk.Login("config..."); std::string result = sdk.Upload(user.name, user.data); if (result.find("success") == std::string::npos) { return false; } return true; } };问题有几个：CloudSyncSDK是具体类，没法Mock；测试要跑就会真实调用SDK登录和上传，可能污染线上数据。改造第一步，把SDK封装成接口：
class ICloudSyncSDK { public: virtual ~ICloudSyncSDK() = default; virtual void Login(const std::string& config) = 0; virtual std::string Upload(const std::string& name, const std::string& data) = 0; };改造第二步，让真实SDK实现这个接口，或者写一个适配器类实现接口并调用真实的CloudSyncSDK：
class RealCloudSyncSDK : public ICloudSyncSDK { public: void Login(const std::string& config) override { CloudSyncSDK sdk; sdk.Login(config); } std::string Upload(const std::string& name, const std::string& data) override { CloudSyncSDK sdk; return sdk.Upload(name, data); } };改造第三步，把UserSync改为通过构造函数接收接口：
class UserSync { public: explicit UserSync(ICloudSyncSDK* sdk) : sdk_(sdk) {} bool Sync(UserInfo user) { sdk_->Login("config..."); std::string result = sdk_->Upload(user.name, user.data); return result.find("success") != std::string::npos; } private: ICloudSyncSDK* sdk_; };测试就好写多了：
class MockCloudSyncSDK : public ICloudSyncSDK { public: MOCK_METHOD(void, Login, (const std::string& config), (override)); MOCK_METHOD(std::string, Upload, (const std::string& name, const std::string& data), (override)); }; TEST(UserSyncTest, SyncFailsWhenUploadResultNotSuccess) { MockCloudSyncSDK mock_sdk; UserSync sync(&mock_sdk); EXPECT_CALL(mock_sdk, Login(_)).Times(1); EXPECT_CALL(mock_sdk, Upload(_, _)).WillOnce(Return("failure")); UserInfo user; user.name = "test"; user.data = "data"; EXPECT_FALSE(sync.Sync(user)); }这个改造的实质，是把“类直接创建依赖”变成“类持有一个依赖接口”，外部把具体实现传进来。接口隔离解耦，依赖注入控制替换，可测试性就这样建立起来了。
3.4 面向接口编程的“度”：别把每个类都抽一遍
有一种矫枉过正的做法：把所有类都先抽成接口，再来个BImpl、CImpl，哪怕这个类根本没有任何替换需求。这种设计会让工程类数量爆炸，阅读代码时要跳很多层，白白增加维护成本。
我的建议是，可以从“替换动机”出发来决定是否抽象接口：这个类是否依赖外部资源（网络、DB、时间、随机数）？这个类是否有真实且不同的实现会同时存在？这个类是否被其他类以复杂协作方式使用？如果三个问题都是“否”，就保持具体类即可。如果只有一个“是”，就值得考虑接口隔离。
还有一个稍微“轻”一点的方案：只把需要Mock的方法做成虚函数，不用抽象出独立接口：
class Logger { public: virtual ~Logger() = default; void Log(const std::string& msg) { // 真实实现 } virtual bool IsEnabled() { return true; } };测试时可以继承Logger，重写IsEnabled方法。但这种方式的问题在于：Mock的替换点不够清晰，一个类里虚方法和普通方法混在一起，读代码时难以判断哪些是设计上的扩展点、哪些只是为测试准备的。如果有两个以上方法需要替换，我建议还是抽接口更清爽。
4. 常见问题与排查技巧实录
4.1 EXPECT_CALL明明写了却不生效，查哪里
这是新手最容易卡住的问题，也是最容易怀疑人生的时刻。写好的EXPECT_CALL，运行测试时却告诉你“unexpected call”。常见原因有这么几个：
第一个原因是对象实例不匹配。测试里构造了MockHttpClient mock_client，但被测类接收的是另一个指针，比如被测类内部拷贝了指针或者你传入了一个新创建的Mock对象，那么EXPECT_CALL设置的预期就绑定在被测对象内部的实例上，实际调用也发生在这个实例上，两者不匹配，gMock自然认为这是“unexpected call”。
第二个原因是Mock方法签名和基类不一致。比如基类是const成员函数，Mock方法忘了写const，那么Mock类就生成了一个新方法而非覆写基类方法。被测类调用的是基类虚函数，走的还是原逻辑，EXPECT_CALL自然不会被命中。排查时先用override关键字确保方法签名一致，编译期能帮你抓出一部分错误。
第三个原因是被测类持有的是一个值拷贝而不是指针或引用。场景通常是这样的：构造函数参数是HttpClient，不是HttpClient*，传进去时发生拷贝，Mock对象和被测类内部的对象是两个独立实例。EXPECT_CALL绑定了外部Mock对象，而实际调用发生在拷贝出的实例上。
排查这类问题，可以先在EXPECT_CALL命中或不命中的方法里加一个断点日志，确认运行时到底走进哪条路径；再把被测类中依赖指针改为引用类型，避免无意的拷贝；最后核对EXPECT_CALL里对象的生命周期，确保Mock对象在被测类销毁之前仍然存活。
4.2 "Uninteresting mock function call"警告与析构时崩溃
有时候你设置了一个EXPECT_CALL，但被测代码还调用了同一个Mock对象的另一个方法，这个方法没被EXPECT_CALL。此时默认的NaggyMock会输出类似“GMOCK WARNING: Uninteresting mock function call”的警告，但测试不会立刻失败。
问题在于，很多人忽略了警告，到Mock对象析构时，gMock发现还有已经设置的预期没有满足，会输出“EXPECT_CALL failed”并导致测试失败。为什么会产生这种奇怪的“延迟失败”？因为gMock的预期检查通常在Mock对象析构时进行，它会检查每条EXPECT_CALL的Times是否达到预期，没达到就算失败。
解决办法也是分几步走：
- 如果那个方法本来就不关心，把它对应的EXPECT_CALL改成NiceMock整体处理，或者在那些不想关心的调用上设置EXPECT_CALL(...).Times(AnyNumber())表示允许任意次数调用
- 如果预期设置正确，只是调用路径没走到，那就检查为什么没走到，这才是真正要发现的bug
- 如果要强制约束所有非预期调用，用StrictMock，这样错误会在第一时间暴露，而不是拖到析构
我的习惯是：先声明Mock对象时就用NiceMockNiceMock<MockHttpClient> mock_client;，把测试关注点收窄到核心交互上，写稳之后再逐步收紧。
4.3 私有方法、非虚方法、普通成员函数到底能不能Mock
直接给结论：不能。至少gMock不能直接Mock它们，原因在于Mock的本质是继承和多态，它只能拦截通过虚函数表分派的调用。如果一个方法不是虚函数，编译期间调用点直接绑定到具体地址，Mock对象根本无法改变这个分发路径。
那怎么办？最实用的是重构被测类，把私有方法的逻辑提取到一个公开的虚接口中，或者抽成独立类再注入。另一种思路是放弃Mock，直接测它暴露的公共方法，虽然依赖没隔离，但至少逻辑覆盖到了。如果被测类和外部依赖纠缠在一起，还动不动就真实连网、真读写文件，那说明问题不在测试代码而在于设计——需要用上一部分讲到的依赖注入重构。
这里有个值得提的点：有人会用模板和编译期技术来“绕过”虚函数限制，比如把依赖作为模板参数传入，在测试时传入一个替代类。这在C++里确实可行，而且有些场景下是更好的方案，但代价是模板代码的可读性和编译错误信息都会变差，对团队协作不太友好。除非你已经对模板元编程很熟练且需要极致性能，否则我建议优先用虚接口方案。
4.4 调用顺序验证与更精细的交互校验
单元测试经常要验证“先做什么、后做什么”。比如上传文件前必须校验权限，权限校验失败就不能执行上传。gMock给了一个很好的工具InSequence：
using ::testing::InSequence; TEST(UserSyncTest, UploadCalledAfterPermissionCheck) { MockCloudSyncSDK mock_sdk; UserSync sync(&mock_sdk); InSequence seq; EXPECT_CALL(mock_sdk, Login(_)).Times(1); EXPECT_CALL(mock_sdk, Upload(_, _)).Times(1); }InSequence要求后面这些EXPECT_CALL之间的调用顺序必须完全一致，否则测试失败。要注意它只管“这些预设之间相对顺序”，不强制要求它们之间没有其他调用。如果连“A调用时B还没被调用过”这种绝对约束也要验证，需要用Times(0)配合，或者用Invoke高级场景记录调用历史。
除此之外，还有一个容易被忽略的武器：Times。不仅仅可以写Times(1)、Times(2)，还可以写Times(AtLeast(1))、Times(AtMost(3))、Times(Between(2, 4))。对于“这个方法至少要被调用一次但具体几次不确定”的场景，这些匹配器非常有用。
4.5 常见错误速查表
| 症状 | 原因 | 处理方案 |
|---|---|---|
| unexpected call | Mock对象和被测对象不是同一实例，或方法签名不一致 | 检查指针传递、修正签名、确认生命周期 |
| 析构时EXPECT_CALL failed | 设置了预期但实际调用没发生，或提前回归逻辑 | 检查调用路径、检查Times设置 |
| 大量warning输出 | 非预期调用触发NaggyMock警告 | 改为NiceMock或补上Times(AnyNumber()) |
| 编译报错“is not a member” | MOCK_METHOD写错签名或遗漏override | 核对基类签名、加override |
| 被测方法里调用了真实依赖 | 依赖不是虚函数/接口 | 重构被测代码，构造函数注入接口 |
| 测试因为IO/网络不稳定失败 | 依赖没被隔离 | 把外部依赖抽象成接口后Mock |
| 调用顺序错乱导致问题 | 多个EXPECT_CALL被乱序触发 | 用InSequence或配合Times约束 |
这表看着简单，但每一条背后都是实实在在踩过的坑。尤其是“Mock对象和被测对象不是同一实例”这条，我在项目里见过不下五次，多数是因为构造函数传值而不是传引用，或者被测类内部又对指针做了浅拷贝/深拷贝操作。排查这类问题的通用技巧是在测试入口打日志，输出Mock对象的地址和被测类内部保存的地址，一对比就清楚了。
写在最后：Mock是一面镜子，照出设计的质量
回头看一下，Mock能不能用好，其实不仅仅是选择工具和写语法的问题。一个类写好之后如果单测上Mock特别吃力，那大概率是这一类在依赖管理上出了问题——耦合太多、替换点不够、层次不清。把Mock用好的过程，往往就是把这个类设计理顺的过程。
我个人在实际项目中有个体会：Mock工具本身能帮你抓到很多交互层的bug，但它改变不了糟糕的代码结构。真正的收获其实来自因为要Mock而不得不做的可测试性设计：接口抽象、构造函数注入、单一职责。这些设计最终受益的不只是测试，还包括代码的可读性和可维护性。所以，如果有哪一天的测试因为Mock太麻烦而让你想“换一个框架解决”，先想一想是不是应该先回头看看被测类的依赖长什么样。
