# FakeIt for C++: Header-Only Mocking and Verification > FakeIt is a header-only C++ mocking framework for arranging method behavior, verifying calls and creating spies across GCC, Clang, AppleClang and MSVC. Its main trade-off is its dependency on C++11 language features and the recommendation to test builds with reduced optimization. **eranpeer/FakeIt** — C++ mocking made easy. A simple yet very expressive, headers only library for c++ mocking. - Repository: https://github.com/eranpeer/FakeIt - Stars: 1,372 · Forks: 181 - Language: C++ - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/eranpeer-fakeit ## What FakeIt Changes in C++ Tests FakeIt addresses the need to test C++ code that depends on interfaces, virtual methods or other collaborators without introducing a production dependency on an implementation. The target users are C++ developers writing unit tests, especially teams that already use an Arrange-Act-Assert style and want mocks and spies directly in test code. The repository describes FakeIt as a simple, expressive, headers-only mocking library written in C++11. It says the library can be used for testing both C++11 and later C++ projects. Its README presents mock creation, behavior configuration and verification as the central workflow, rather than requiring a separate mock-generation step or a library binary linked into the test executable. The practical scope is narrower than a full application-testing environment. FakeIt supplies mocking behavior for C++ interfaces and methods. The README does not describe broader test discovery, reporting, fixtures, parameterization, coverage management or test-runner installation. Those concerns remain the responsibility of the test framework selected by the project. FakeIt can integrate its generated error messages with several test frameworks, including GoogleTest, MSTest, Boost.Test, Catch2, tpunit++, mettle, Qt Test, NUnit, CUTE and doctest, but it does not replace them. ## Mock Behavior, Calls and Verification FakeIt uses C++ expressions to configure a mock and then exposes a reference that application code can call. In the README example, `Mock` creates a mock object. `When(Method(mock,foo)).Return(1)` configures `mock.foo` to return `1` once, and `mock.get()` supplies a `SomeInterface&` reference. The verification mechanism records or checks method invocations through the same `Method` expression. `Verify(Method(mock,foo))` checks that `mock.foo` was invoked, while `Verify(Method(mock,foo).Using(1))` checks that it was invoked with the specific argument `1`. This gives a test two distinct controls: the return value used by the code under test and the expectation applied after the test action. The feature list also identifies dynamic casting, an unlimited number of method arguments, and the ability to create spy objects from existing objects. The README does not provide the full syntax for spy creation, dynamic casting or more advanced return behavior, so those APIs should be checked in the linked Quickstart and repository documentation before adoption. The basic example is concrete enough to show the intended data flow: configure the mock, pass its underlying reference into production code, invoke a method, then verify the method or its arguments. ## Header-Only Installation and a First FakeIt Test FakeIt does not require an installation step when the project uses a pre-packaged header. The README says to choose the `single_header` directory that matches the test framework and add it to the test project's include path. For GoogleTest, the documented include flag is: ```bash -I"/single_header/gtest" ``` The selected directory supplies a configuration that routes FakeIt assertions through GoogleTest. A project using no external test framework can instead use the `standalone` configuration. The repository lists separate pre-packaged directories for `mstest`, `boost`, `catch`, `tpunit`, `mettle`, `qtest`, `nunit`, `cute`, `doctest` and `standalone`. The following is the README's first mock example. It configures a return value, obtains the interface reference and calls the mocked method: ```cpp Mock mock; When(Method(mock,foo)).Return(1); SomeInterface &i = mock.get(); cout << i.foo(0); ``` According to the example, the call prints `1`. The interface definition in the README declares `foo(int)` and `bar(string)` as pure virtual methods. The verification example then calls `i.foo(1)` and checks either invocation generally or invocation with `Using(1)`: ```cpp Mock mock; When(Method(mock,foo)).Return(0); SomeInterface &i = mock.get(); i.foo(1); Verify(Method(mock,foo)); Verify(Method(mock,foo).Using(1)); ``` For source-header use instead of a single header, the README documents adding both the source include directory and the relevant configuration directory: ```bash -I"/include" -I"/config/gtest" ``` It also documents CMake installation from a cloned repository: ```bash cmake -S . -B build -DCMAKE_INSTALL_PREFIX= cmake --build build cmake --install build ``` After installation, the documented project integration uses `find_package(FakeIt REQUIRED)` and links `FakeIt::FakeIt-` to the test target. Replace `` with the appropriate configuration name, such as `gtest`, and pass `-DFakeIt_ROOT=` when configuring the consuming project, as the README describes. ## Framework Integration and Build Constraints The most important integration choice is the FakeIt configuration name. `gtest`, `mstest`, `boost`, `catch`, `tpunit`, `mettle`, `qtest`, `nunit`, `cute` and `doctest` are documented pre-configurations. `standalone` is the fallback when the test framework is not on the list. The pre-packaged header route reduces setup to one include directory, while the source-header route requires both `include` and the selected `config/` directory. The README lists CI targets for Linux with GCC and Clang, macOS with AppleClang and Windows with MSVC. That is evidence of documented compiler coverage, not a guarantee that every project, standard-library implementation or build configuration will behave identically. The library is based on C++11 expressions, so a project that cannot compile C++11 syntax is outside the documented fit. There is also a specific compiler and optimization caveat. The README recommends `-O1` or `-O0` for GCC because some FakeIt features may not work with stronger optimizations. This is a meaningful adoption constraint for teams that require aggressive release optimization or have build settings enforced by a shared toolchain. The README does not explain exactly which features fail, so the project's own tests should be built in the intended toolchain rather than assuming every optimization level is equivalent. ## Maintenance, License and Alternative Approaches The repository is not archived. Its last push was on 2026-06-30, and the release list includes version 2.5.0 on 2025-11-14, 2.4.1 on 2024-10-06 and 2.4.0 on 2023-04-17. Those dates show recent repository activity and published releases. The README does not document a compatibility policy, semantic-versioning guarantee, migration guide or rollback process, so upgrade planning cannot be inferred from the release list alone. FakeIt is distributed under the MIT license. That identifies the repository's stated license, but it does not by itself answer questions about how a particular organization handles notices, dependencies or distribution. There is no documented runtime dependency in the header-only usage model described by the README. A real alternative is to use generated mocks or a different mock library that integrates with a project's existing test framework and code-generation workflow. The difference is architectural: FakeIt's documented model is direct runtime mock construction and expression-based behavior setup, with no mock-generation step mentioned in the README. A generated-mock approach instead produces test doubles as source artifacts and usually makes the interface shape visible in generated files. Another practical alternative is the test framework's own stubbing facility, if the project already has one. That avoids adding FakeIt's configuration directory, but it does not provide FakeIt's `Mock`, `When`, `Verify` and spy-oriented API. The choice depends on whether one header and direct mock construction matter more than using an existing framework mechanism. ## Where FakeIt Is the Wrong Choice FakeIt is the wrong choice when the required test capability is outside its documented C++ mocking scope. The README does not say that FakeIt manages test execution, produces a complete test report, selects test cases or replaces a test framework. It also does not document a general-purpose stubbing system for non-virtual functions, a separate code-generation workflow or an upgrade migration process. Those omissions matter when a team expects a complete mocking platform rather than a focused header-only library. The optimization warning creates another concrete exclusion. If a GCC build must use stronger optimization and the team cannot run the project tests at `-O1` or `-O0`, FakeIt may not fit that build policy. The README does not identify a workaround, so it would be inaccurate to promise that a specific flag resolves the issue. The library also requires C++11 support and documented compiler families. A codebase restricted to an older C++ standard, or one using a compiler and framework combination not listed in the README, should verify compatibility before standardizing FakeIt across the suite. The single-header distribution also means include-path and configuration mistakes can affect every test target. Those are manageable setup concerns, but they are real costs for a team that wants a fully automated mock-generation pipeline. ## Conclusion Adopt FakeIt for C++ test suites that need small, configurable mocks without a runtime dependency, but verify compiler compatibility, optimization settings and the required integration configuration first. It is less suitable for teams that need a tool outside its documented C++ and testing-framework support. For a new integration, the first project-specific check is whether the selected single header or include and configuration directories build successfully in the target test environment. ## FAQ ### How do I install FakeIt for C++? FakeIt is header-only and does not require a traditional installation. Add the appropriate pre-packaged directory from `single_header` to the test project's include path, or use the source `include` and `config/` directories. ### How do I configure a FakeIt mock to return a value? Use `When(Method(mock,foo)).Return(1)` to configure the mock method. The README's example then obtains the interface with `mock.get()` and calls `i.foo(0)`, which prints `1`. ### How do I verify a FakeIt method call and its arguments? Use `Verify(Method(mock,foo))` to verify that the method was invoked. Add `.Using(1)` to verify a specific argument, as shown in the README. ### Which testing frameworks are supported by FakeIt? The README lists GoogleTest, MSTest, Boost.Test, Catch2, tpunit++, mettle, Qt Test, NUnit, CUTE and doctest. If a framework is not listed, the documented fallback is the `standalone` configuration. ### What compiler and optimization settings does FakeIt require? The README says FakeIt supports GCC, Clang, AppleClang and MSVC. It recommends building with `-O1` or `-O0` for GCC because some features may not work with stronger optimizations. ## Sources - [eranpeer/FakeIt on GitHub](https://github.com/eranpeer/FakeIt) - [Issues](https://github.com/eranpeer/FakeIt/issues) - [License: MIT](https://github.com/eranpeer/FakeIt/blob/master/LICENSE) - [README](https://github.com/eranpeer/FakeIt/blob/master/README.md) - [Releases](https://github.com/eranpeer/FakeIt/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eranpeer-fakeit