【C/C++】单元测试实战：Stub与Mock框架解析

C++ 单元测试中的 Stub/Mock 框架详解

在单元测试中，Stub（打桩）和Mock都是替代真实依赖以简化测试的技术。通常，Stub（或 Fake）提供了一个简化实现，用于替代生产代码中的真实对象（例如用内存文件系统替代磁盘文件系统），而Mock则是在运行时预设了期望行为的对象，用来验证代码与依赖之间的交互是否符合预期。下面我们重点介绍几种常见的 C++ Stub/Mock 框架：Google Mock、FakeIt、Fake Function Framework (FFF) 和 MockCPP（Mock++），并分析它们的特点、使用示例和适用场景。

Google Mock (gMock)

简介：Google Mock（简称 gMock）是 Google Test 库提供的 C++ Mock 框架，用于创建模拟类和方法。它允许使用宏 MOCK_METHOD 来描述要模拟的接口或虚函数，自动生成 mock 类的实现，用户可以通过 EXPECT_CALL 等语法直观地设置预期调用和行为。gMock 功能强大，提供丰富的参数匹配器、调用次数控制和动作指定（如 .WillOnce(Return(x))）等特性，非常适合对面向对象的接口进行精细控制。

安装与集成：gMock 与 Google Test 一起发布。Google Test 源码仓库中就包含了 gMock，可以使用 CMake 或 Bazel 构建整个 googletest 包。也可以通过包管理器（如 vcpkg、conan 等）安装 googletest 包，它们会自动包含 gMock。测试代码中通常需要包含 <gtest/gtest.h> 和 <gmock/gmock.h> 头文件。由于 gMock 与 Google Test 深度集成，使用起来非常方便。

样例代码：下面是一个简单的示例：假设有一个 Calculator 接口，我们为其创建一个 mock 并测试调用行为。

// 被测接口
class Calculator {
public:
    virtual ~Calculator() {}
    virtual int add(int a, int b) = 0;
};

// 创建 Mock 类，继承接口并使用 MOCK_METHOD 宏
class MockCalculator : public Calculator {
public:
    MOCK_METHOD(int, add, (int a, int b), (override));
};

TEST(CalculatorTest, AddTest) {
    MockCalculator mockCalc;
    // 设置预期：调用 add(2,3) 返回 5 且调用一次
    EXPECT_CALL(mockCalc, add(2, 3))
        .Times(1)
        .WillOnce(Return(5));

    // 使用 mock 对象
    int result = mockCalc.add(2, 3);
    ASSERT_EQ(result, 5);
}

以上示例中，MOCK_METHOD 宏在 MockCalculator 类中自动生成了 add 方法的模拟实现；EXPECT_CALL 用于声明对 add 的期望调用（参数和返回值）。当测试执行时，如果模拟对象的使用与期望不符，gMock 会立即报告错误。

优缺点分析：

• 优点：功能强大，特别适合模拟 C++ 类的虚函数/接口，可以细粒度控制方法调用的参数、顺序和返回值。提供了丰富的匹配器（如 _, HasSubstr, 自定义 lambda 等）和动作（WillOnce、WillRepeatedly、DoAll 等），以及验证调用次数的机制。gMock 与 Google Test 紧密集成，文档和社区资源丰富。典型的测试流程符合“Arrange-Act-Assert”模式。
• 缺点：只能模拟类的虚函数或接口方法，对普通的自由函数、全局函数或静态函数支持不好。若被测代码中不使用接口/虚函数，需要重构设计才能使用 gMock。gMock 大量使用宏实现，学习曲线较陡峭，编译速度可能较慢，错误信息有时不够直观。

适用场景：gMock 非常适合纯 C++ 面向对象的场景，如通过接口或虚类进行模块间交互时的测试。比如在测试依赖于数据库、网络等资源的类时，可以定义相应的接口并使用 gMock 来模拟依赖，从而专注于验证业务逻辑。在 C 语言风格或函数指针场景下，通常需要先包装或抽象出接口，gMock 才能使用。

与测试框架结合：gMock 与 Google Test 一起使用。测试代码中可以使用 Google Test 的 TEST 或 TEST_F 来定义测试用例，断言宏（ASSERT_*/EXPECT_*）来自 Google Test。中的流程步骤描述了典型的使用方式：导入 gMock 名称、创建 mock 对象、设置期望、调用被测代码，然后自动校验所有期望。由于 gMock 本身就是 Google Test 的一部分，只要正确引入头文件即可在任何 Google Test 环境下使用。

FakeIt 框架

简介：FakeIt 是一个轻量级的 C++ mocking 框架，基于 C++11 实现，支持 GCC、Clang、MSVC 等主流编译器。它采用头文件级别实现（header-only），提供了简洁而富有表现力的 API：使用 Mock<T> 创建 mock 对象，使用 When(Method(mock, func)).Return(val) 指定返回值，使用 Verify(Method(mock, func)) 验证调用情况。FakeIt 的设计目标是让 C++ mocking 更加易用，用最少的样板代码就能实现常见的 mock 用例。

安装与集成：FakeIt 仅需包含头文件即可使用，无需单独编译库。可以从 FakeIt GitHub 获取源码，或者直接使用单头文件版本（fakeit.hpp 或 fakeit_single_header.hpp）。框架预先配置了与 Google Test、Boost.Test、Catch2 等流行测试框架的集成方案，使得测试断言输出可以与这些框架统一。如果项目没有使用主流框架，也可以使用 FakeIt 的 standalone 模式（自带简单断言机制）。

样例代码：下面演示了 FakeIt 的基本用法，测试一个接口 IFoo 的模拟行为。

struct IFoo {
    virtual ~IFoo() {}
    virtual int foo(int x) = 0;
};

TEST(FakeItTest, Basic) {
    using namespace fakeit;
    // 创建 IFoo 的 mock 对象
    Mock<IFoo> mockFoo;
    // 设置 foo 方法被调用时返回 42
    When(Method(mockFoo, foo)).Return(42);

    // 从 mock 对象获取接口引用
    IFoo &iFoo = mockFoo.get();
    int result = iFoo.foo(10);
    ASSERT_EQ(result, 42);

    // 验证 foo 是否被调用过一次
    Verify(Method(mockFoo, foo));
}

上述代码中，Mock<IFoo> mockFoo 创建了一个 IFoo 的模拟实例；When(Method(mockFoo, foo)).Return(42) 指定当调用 foo 时返回 42；mockFoo.get() 则获取该 mock 的引用用于测试调用。最后 Verify(Method(mockFoo, foo)) 用于验证 foo 至少被调用过一次。FakeIt 的语法直观，通常只需一两行代码就能完成设置和验证。

优缺点分析：

• 优点：API 简洁、使用成本低。作为头文件库，无需额外安装步骤，易于集成到任意项目。支持所有主流编译器和 C++11/14/17 标准；框架提供对现有对象的“间谍（Spy）”功能，可在不修改生产代码的情况下监控调用。FakeIt 预先配置了对 Google Test、Boost.Test 等常见框架的兼容性，测试报告样式统一。其 Arrange-Act-Assert 风格清晰，使测试代码可读性高。
• 缺点：功能上相对 gMock 稍逊一筹，例如对复杂场景（调用序列、回调等）的支持有限。在较早版本中，错误信息和调试支持也不如 gMock 丰富。由于社区较小，可参考的中文资料有限，学习资源不如 Google 官方那么多。但对于一般的函数调用场景，FakeIt 已经足够简便强大。

适用场景：FakeIt 适用于需要快速创建 mock 并且代码已经使用接口或虚函数设计的 C++ 项目。它可以方便地模拟依赖接口，专注于测试逻辑而不启动实际组件。例如，在测试与数据库交互的类时，可以用 FakeIt 模拟数据库接口，控制返回数据，验证业务逻辑如何处理这些数据。FakeIt 也支持对已有实例“监控”，适合在不修改生产代码前提下捕获方法调用并验证行为。

与测试框架结合：FakeIt 与 Google Test 等框架可以很好地配合。例如，上述示例使用了 Google Test 的 TEST 和断言宏。FakeIt 内部提供了与这些框架的集成配置（如 #include "fakeit.hpp" 会自动链接对应的测试框架断言机制），使得 FakeIt 的错误信息可以直接作为 Google Test 的失败报告。除了 Google Test，FakeIt 也支持 Catch2、Boost.Test 等，只需在包含头文件时使用不同配置即可。

Fake Function Framework (FFF)

简介：Fake Function Framework（简称 FFF）是一个面向 C 语言的微型假函数框架，用于创建 C 函数级别的测试替身。它非常轻量，完全用宏实现，适合对纯 C 代码（特别是嵌入式系统中的 C 接口）进行单元测试打桩。FFF 可以自动记录函数调用次数和参数值，而不需要编写手动的 fake 函数。它的设计初衷是“让测试假函数的创建不再乏味”。

安装与集成：FFF 也是头文件实现，只需下载 fff.h 并在测试代码中包含即可使用。通常将 fff.h 文件置于测试项目中，写 #include "fff.h" 后通过定义宏开启功能，比如 DEFINE_FFF_GLOBALS;。然后可以使用 FFF 提供的宏来定义假函数。FFF 不依赖特定的测试框架，常与 Ceedling/Unity（C 语言测试工具）一起使用，但也可以在 C++ 项目中通过 extern "C" 包装后与 Google Test 等框架结合。

样例代码：假设有一个 C 语言函数 void hardware_init() 需要在测试中模拟：

// 在 test.c(pp) 中：
#include "fff.h"
DEFINE_FFF_GLOBALS;
FAKE_VOID_FUNC(hardware_init);

TEST(CFunctionTest, InitTest) {
    // 调用被测代码（假设其中会调用 hardware_init()）
    system_init();

    // 验证 hardware_init() 被调用了一次
    ASSERT_EQ(hardware_init_fake.call_count, 1);
}

上例中，FAKE_VOID_FUNC(hardware_init) 宏定义了一个名为 hardware_init 的假函数，并生成对应的控制结构体（hardware_init_fake）。当调用 system_init() 时，如果它内部调用了 hardware_init()，那么 hardware_init_fake.call_count 将被增加。测试最后通过断言检查调用次数。对有返回值的函数，可以使用 FAKE_VALUE_FUNC(retType, func, args...)；对带参数的函数，宏会自动生成相应的参数记录（例如 foo_fake.arg0_val 等）。

优缺点分析：

• 优点：极为轻量和简单，特别适合 C 语言环境的测试。不需要复杂的构建，直接包含头文件即可使用。对于纯 C 函数（如硬件驱动接口），可以快速生成假函数并自动统计调用次数和参数，极大减少手写 stub 的工作量。依赖少，适用于嵌入式系统等对资源敏感的场景。
• 缺点：功能有限，仅能处理全局或静态 C 函数的调用情况，无法模拟 C++ 类的成员函数。它不提供像 gMock 那样的复杂行为控制或断言功能，只能记录调用次数和参数值，需手动编写断言或返回逻辑。对于面向对象的设计场景，FFF 无法直接使用；此时需要将依赖包装成 C 接口才能用 FFF 打桩。

适用场景：FFF 主要用于 C 风格的代码测试，特别是嵌入式软件的硬件抽象接口测试。它适用于替代库函数、驱动函数等，例如模拟 I/O、时钟、中断等函数调用。对于 C++ 类、虚函数和接口，FFF 不适用。通常在需要 Stub 出单个函数行为时使用 FFF，而不用于复杂的 Mock 行为验证。

与测试框架结合：FFF 本身只负责假函数的生成，不包含断言框架。因此，测试时可以选择任意 C/C++ 测试框架来执行断言。例如，可以在 Google Test 的 TEST 中包含 fff.h 并使用 ASSERT_EQ 来检查 foo_fake.call_count。在 C 项目中，也常与 Ceedling/Unity 配合使用（Unity 对 foo_fake.call_count 做断言），从而实现测试打桩。不过需要注意 FFF 的宏通常定义为 C 风格，全局变量名可能会与测试框架中的符号冲突，需要妥善管理。

MockCPP (Mock++)

简介：MockCPP（又称 Mock++）是一个跨平台的 C++ Mock 框架，受 jMock 等 Java 框架启发设计。它使用 C++11 的可变参数模板和宏来实现 Mock 功能，目标是在不依赖编译器内部机制的情况下提供简单的 Mock 支持。MockCPP 的核心思想是：对虚函数进行模拟，需要通过继承和宏来声明要模拟的函数，然后在测试中设置行为和验证调用。

安装与集成：MockCPP 可从其 GitHub 仓库 克隆获取，编译时需要支持 C++11。它不像 gMock 那样集成于常用测试框架，而是一个独立的库，编译后链接到测试项目。使用时，在测试代码中包含 MockCPP 的头文件，如 #include <mockpp/mockpp.h> 以及需要的头。MockCPP 本身不提供断言功能，因此通常与 Google Test、Boost.Test 等一起使用。只要在测试用例中创建了 Mock 对象并设置期望，就可以使用测试框架的断言来检查验证结果。

样例代码：下面示例演示了使用 MockCPP 模拟一个 IWidget 接口及其方法调用：

class IWidget {
public:
    virtual ~IWidget() {}
    virtual bool isReady() = 0;
};

class MockWidget : public IWidget, public mockpp::Mock<IWidget> {
public:
    MOCK_FUNCTION(bool, isReady);
};

TEST(MockCPPTest, Basic) {
    MockWidget widget;
    using namespace mockpp;
    // 设置调用 isReady 时返回 true
    PROBE(&widget, isReady).toReturn(true);

    // 调用 mock 方法
    bool r = widget.isReady();
    ASSERT_TRUE(r);

    // 验证 isReady 被调用
    ASSERT_TRUE(VALIDATE(&widget, isReady).called());
}

示例中，MOCK_FUNCTION(bool, isReady); 宏在 MockWidget 类中声明了要模拟的 isReady 方法。在测试中使用 PROBE(&widget, isReady).toReturn(true) 指定调用时返回值为 true。最后使用 VALIDATE(&widget, isReady).called() 来验证该方法确实被调用过。MockCPP 的 PROBE 和 VALIDATE 类似于 gMock 的 EXPECT_CALL 和验证机制，但表达方式不同。

优缺点分析：

• 优点：MockCPP 实现简洁，完全基于标准 C++11，不依赖于非标准特性（如内部 vtable），具有良好的可移植性。通过宏声明和模板实现，编译器兼容性强。框架本身较轻量，在某些需要对编译器支持有严格要求的项目中可能更受青睐。MockCPP 提供了类似 gMock 的调用顺序验证（默认严格顺序），也支持放松验证（RelaxedMock 模板）等高级功能。
• 缺点：使用的人较少，文档和社区支持有限。需要手动继承接口并编写 mock 类，使用门槛较高。与 gMock/FakeIt 相比，缺少现成的匹配器和动作链（虽然可以用 C++11 lambda 自行实现类似功能）。MockCPP 主要针对基于类的接口场景，对纯 C 函数或数据驱动的场景不适用。

适用场景：MockCPP 适用于需要模拟 C++ 类和接口的场景，与 gMock/FakeIt 作用相似。例如在需要严格控制调用顺序的测试中，可以利用 MockCPP 默认的严格验证机制。由于其标准化实现，也可用于对可移植性要求高的项目。对于 C 风格的代码或函数指针场景，MockCPP 不适用，此时应选择 FFF 等其他工具。

与测试框架结合：MockCPP 与常见 C++ 单元测试框架配合使用。例如示例中我们使用了 Google Test 的 TEST 和断言。MockCPP 不包含自己的断言机制，通常在测试中使用 Google Test 的 ASSERT_TRUE、ASSERT_EQ 等来判断 VALIDATE() 的结果。也可以在 Boost.Test 或其他框架中同样使用，只要在测试结束时检验 mock 对象的调用情况即可。

Trompeloeil 框架

Trompeloeil 是一个**面向现代 C++（C++14 及以上）**的静态类型（statically typed）模拟框架。与许多旧式模拟框架不同，它利用 RAII 机制来管理期望（expectation）的生命周期，并提供类似自然语言的表达方式来描述动作、过滤器、副作用和返回值等。该框架采用头文件单一依赖（header-only），无需额外链接库，并采用 Boost Software License 1.0 开源授权。

• 安装集成：Trompeloeil 以头文件方式分发。可以通过 GitHub 仓库 克隆后直接将 trompeloeil.hpp 包含到测试项目中，也可通过包管理工具（如 Conan）引入最新版。只需确保编译器支持 C++14 即可（GCC 4.9、Clang 3.5+ 等），无需其他依赖。

• 核心用法示例：Trompeloeil 的基本使用方式与 Google Mock 类似：首先定义一个继承自要模拟接口的 Mock 类，并使用宏 MAKE_MOCKn 或 MAKE_CONST_MOCKn 来创建模拟函数。例如，假设接口 Warehouse 有两个虚函数 hasInventory 与 remove，可写：

  class WarehouseMock : public Warehouse {
  public:
    MAKE_CONST_MOCK2(hasInventory, bool(const std::string&, size_t));
    MAKE_MOCK2(remove, void(const std::string&, size_t));
  };
  

  然后在测试中设置期望和返回值，用 REQUIRE_CALL 宏：

  TEST_CASE("Order is filled when inventory is sufficient", "[Trompeloeil]") {
    Order order("Whisky", 50);
    WarehouseMock warehouse;
    REQUIRE_CALL(warehouse, hasInventory("Whisky", 50))
      .RETURN(true);
    REQUIRE_CALL(warehouse, remove("Whisky", 50));
    order.fill(warehouse);
    REQUIRE(order.is_filled());
  }
  

  上述代码中，REQUIRE_CALL 表示被测代码必须在测试作用域结束前调用指定的模拟方法，否则测试失败。Trompeloeil 还支持顺序验证（trompeloeil::sequence）、通配符 _、抛出异常、替代函数实现等高级功能。

• 优缺点：

  • 优点：Trompeloeil 支持强类型（编译时）检查，语法直观、灵活，且通过 RAII 确保在析构时验证所有期望。它无需链接额外库（头文件实现），升级方便，并持续活跃维护（最近版本支持协程、正则匹配等新特性）。
  • 缺点：仅支持模拟虚函数（接口方法），无法直接模拟普通全局函数或非虚成员函数（需要通过间接依赖注入来变通）。此外，要求项目使用 C++14 以上标准，老旧编译器下语法可能受限。由于高度灵活，有时错误信息对新手可能不够直观。

• 适用场景：Trompeloeil 非常适合模拟面向接口编程的 C++ 代码（使用纯虚基类或抽象类）。它在处理复杂的对象交互和高级匹配条件（如多重参数、序列要求）时非常方便。但对于 C 样式函数、函数指针或全局函数等非类成员函数，则需要其他框架（如 HippoMocks、FFF）来补充支持。

HippoMocks 框架

HippoMocks（常称 Hippo Mocks）是由 Wouter van Ooijen 编写的一个单头文件C++模拟框架，面向 C++11 及以上的环境。它最初是作者个人使用的轻量库，现在开源发布，并且无需任何第三方依赖。HippoMocks 的主要特点是支持多种函数类型的模拟，包括类成员函数、全局函数、静态函数等（但静态函数必须可被链接hook），这在 C++ 模拟库中较为少见。

• 安装集成：使用 HippoMocks 非常简单。只需从GitHub 仓库下载单个头文件 hippomocks.h，然后在测试代码中包含它即可。它与常见的测试框架（如 CppUnit、Google Test）兼容，通过 MockRepository 对象来管理模拟实例。

• 核心用法示例：HippoMocks 通过 MockRepository 创建模拟对象，并使用 ExpectCall 等方法设定期望。例如，要模拟如下接口：

  struct IBar {
      virtual void b() = 0;
      virtual int c(const std::string&) = 0;
      virtual ~IBar() = default;
  };
  

  在测试中可以这样写：

  TEST_CASE("HippoMocks example", "[Hippo]") {
    MockRepository mocks;
    // 创建接口 IBar 的模拟
    IBar* barMock = mocks.Mock<IBar>();
    // 设定期望：方法 b() 必须被调用
    mocks.ExpectCall(barMock, IBar::b);
    // 设定期望：方法 c("hello") 返回 42
    mocks.ExpectCall(barMock, IBar::c)
         .With("hello")
         .Return(42);
    // 被测代码调用 barMock...
    REQUIRE(barMock->c("hello") == 42);
    // 作用域结束时 MockRepository 析构，会检查所有期望是否满足:contentReference[oaicite:16]{index=16}。
  }
  

  上述代码中，ExpectCall(barMock, IBar::c).With("hello").Return(42) 直接说明：调用 barMock->c("hello") 时返回 42。HippoMocks 还支持 Throw() 抛异常、OnCall()（可选调用）、Do() 执行自定义替代函数等高级功能。与其他库相比，HippoMocks 的语法也接近自然语言，代码可读性较好。

• 优缺点：

  • 优点：HippoMocks 最大的优势是无需依赖（仅包含头文件）且使用简单。它支持 Windows、Linux、Mac 等主流平台（MSVC、GCC、Clang），并且可以模拟静态/全局函数，这是多数 C++ Mock 框架无法做到的（需要函数在编译时未被内联）。此外，由于框架年头较久，社区示例和教程较多（例如 Assembla wiki 等），学习成本低。
  • 缺点：HippoMocks 的文档相对稀缺（官方未提供详尽参考），出错时的错误信息不够友好，调试难度较大。由于采用底层方法（动态链接钩子）来实现静态函数模拟，其机制可能不被所有平台完全支持，而且对内联函数无能为力。此外，HippoMocks 的更新频率已经很低（最新发布在 2016 年左右），项目维护不如 Trompeloeil 和 FakeIt 活跃。

• 适用场景：HippoMocks 非常适合对已有 C 代码或混合 C/C++ 项目进行单元测试时使用，尤其是需要模拟非类成员函数时（例如模拟系统调用、库函数）。对于接口式设计的 C++ 类，HippoMocks 也能轻松应对。但它不属于静态类型框架，对模板或重载可能需要额外处理（可以使用 ExpectCallOverload 显式指定函数签名）。当需要集成到现有的 C++ 测试框架时，只需包含头文件即可，无需链接额外库。

Catch2 自带的 Mock/Fake 能力

Catch2 本身是一个流行的 C++ 单元测试框架（支持头文件形式，无需链接）。需要明确的是，Catch2 并不提供内置的完整模拟功能。JetBrains 文档也指出：“与 Boost.Test 类似，Catch2 不提供模拟功能。但可以将其与独立的模拟框架（如 HippoMocks、FakeIt、Trompeloeil 等）结合使用”。换言之，Catch2 倾向于专注测试运行和断言逻辑，而将 Mock 交给第三方库来完成。

• 内建 Fake 功能：虽然 Catch2 没有专门的模拟模块，但在 Catch2 v3 中提供了一些辅助支持。例如，Catch2 的 “extras” 中包含了用于与 Trompeloeil 等框架配合使用的头文件（如 <catch2/trompeloeil.hpp>），方便在 Catch2 测试文件中使用 Trompeloeil 宏。如果选择使用 FakeIt，还可以在 CMake 中配置 FakeIt 的 catch 预定义版本，使其自动集成 Catch2 的断言机制。总的来说，Catch2 自身没有专用的 REQUIRE_CALL 或 EXPECT_CALL 等接口，但可以通过引入其他库来实现类似功能。

• 示例：假设借助 FakeIt 在 Catch2 测试中使用模拟对象，可以按 FakeIt 文档设置配置：

  // 假设已经在 CMake 中引入了 Catch2 和 FakeIt
  #include "fakeit.hpp"
  #include <catch2/catch_test_macros.hpp>
  using namespace fakeit;
  
  struct SomeInterface {
      virtual int foo(int) = 0;
      virtual ~SomeInterface() = default;
  };
  
  TEST_CASE("Catch2 + FakeIt example", "[FakeIt]") {
      Mock<SomeInterface> mock;
      When(Method(mock, foo).Using(5)).Return(10);
      SomeInterface& i = mock.get();
      REQUIRE(i.foo(5) == 10);
      Verify(Method(mock, foo).Using(5)).Exactly(1);
  }
  

  如上，Catch2 测试框架负责执行断言 (REQUIRE)，而 FakeIt 负责定义模拟逻辑。FakeIt 提供预配置的 catch 配置，能无缝打印断言失败信息。

• 优缺点：

  • 优点：如果项目已经使用 Catch2 进行单元测试，集成其他 Mock 框架相对容易。例如上述示例无需链接额外库，只需要包含适当头文件。Catch2 支持多种断言类型和 BDD 风格，可用于测试生成数据、参数化测试等场景，其测试执行速度较快。对于简单需求，可以通过 Catch2 的 GENERATE 或 SECTION 等功能模拟不同的输入情形，算是一种“轻量级”的伪模拟用法。
  • 缺点：因为没有内置专门的 Mock 接口，实现模拟需要额外引入第三方库。使用 Catch2 配合 Mock 框架时，需要考虑集成配置（如链接 FakeIt 的 Catch 集成头）。Catch2 也不直接支持模拟非虚函数或全局函数，这些问题仍需依赖 HippoMocks、FFF 等专门工具来解决。总结来说，Catch2 作为测试框架本身不作为模拟框架使用，它的“Fake”功能实际上是对其他库的依赖或利用基本测试功能模拟输入。

框架对比与适用场景

下表对比了 Trompeloeil、HippoMocks、Catch2（配合 FakeIt）、以及常见的其它框架（gMock、FakeIt、FFF、MockCPP）在功能特性方面的差异：

说明：表中“模拟目标”指框架设计时主要支持的被模拟对象类型。比如 Trompeloeil、gMock、FakeIt、MockCPP 均以 C++ 接口类（纯虚函数）为目标；HippoMocks 和 FFF 则能模拟普通函数/静态函数。C++ 版本要求和许可证摘自官方说明。Catch2 本身不限制 C++ 标准，但与 FakeIt 结合时需要至少 C++11。维护状态一栏基于最近代码提交和发行情况概括。

从上述对比可以看出：

• Trompeloeil 适合进行现代 C++ 编程时的接口模拟，语法与 GoogleMock 类似但更加现代化。
• HippoMocks 适合需要模拟 C 风格函数或已有非面向接口代码的场景，因其 Hook 特性可拦截全局/静态调用。
• Catch2 自身更偏向作为测试运行器，适合简单场景或与其他框架结合使用；如果不需要复杂 Mock，也可直接编写替身函数（Fake 函数）和 GENERATE 配置来模拟不同输入。
• gMock/FakeIt 常与 Google Test 或其他测试框架配合使用，是成熟的选择。FakeIt 作为轻量级单头文件框架易上手，而 gMock 功能最丰富。
• FFF 专门用于 C 函数模拟，适用于嵌入式或遗留 C 代码测试。
• MockCPP 作为早期框架，现在用途较少，新项目一般使用上述更现代的框架。

小结

综上，Trompeloeil、HippoMocks 和 Catch2（配合 FakeIt）各有侧重。Trompeloeil 提供了表达能力强、类型安全的 C++ 接口 Mock 功能；HippoMocks 则通过轻量级单头文件方式支持更多函数形式，包括非对象函数。Catch2 本身不带模拟机制，只负责管理测试生命周期，但可灵活地与任意 Mock 库集成。在选择框架时，应根据项目语言标准、代码风格（面向接口或过程式）、平台兼容性等因素综合考虑。通过比较以上框架的特点，可以为不同场景选用合适的模拟工具，提高单元测试的编写效率和代码质量。