CMock: a mock and stub generator that reads your C headers

The generator reads headers, you do not write mocks by hand

CMock is described as a mock and stub generator and runtime for unit testing C, and the phrase that explains the whole design is that it automagically parses your C headers and creates useful and usable mock interfaces. The input is the header file, the output is a set of C files that stand in for the real module. A hand written mock for a module with a dozen functions is a dozen sets of stubs, plus a dozen places to update when a signature changes. Generating them from the header removes the duplication, and the header stays the single source of truth for the interface. The consequence is that CMock is a code generator rather than a library, so it belongs in your build, not in your source tree as a link-time dependency. The repository layout reflects that split, with a lib directory holding the generator, a src directory holding the runtime support, a config directory, a scripts directory and a vendor directory for the bundled dependencies.

Unity is the sibling tool, and the pair is designed together

CMock is explicitly built to work smoothly with Unity Test, another of the embedded-software testing tools developed by ThrowTheSwitch.org. That is the intended shape of a CMock project. Unity provides the test runner, the assertion macros and the setUp and tearDown convention, and CMock provides the stand-in implementations of the modules under test. A test file then asserts against a mock, and Unity reports the result. The project also lists a Known Issues document at docs/CMockKnownIssues.md and a Change Log at docs/CMockChangeLog.md, which is worth reading before you commit because a mock generator has a lot of edge cases around variadic arguments, pointer returns and callbacks, and a maintained list of them tells you where the sharp edges are. The examples directory holds two worked cases, a make_example project and a temp_sensor project, and the README points there for concrete usage rather than trying to describe it in prose.

If you do not want to manage the build, Ceedling owns it

There is a fork in the road in the getting started instructions, and choosing wrong costs you a day. The first path is Ceedling, a test-centered build manager for unit testing C code. If you use Ceedling there is no need to install CMock, because it handles it for you. That is the right choice for a team that wants a working unit testing build without designing one, and it is the path the README points at first when it says to consider checking out Ceedling if you do not care to manage unit testing builds yourself. The second path is driving CMock yourself, which means the mock generation step, the test compile and the test run all live in your own build system, and the Ruby tool has to be available wherever that build runs. The repository contains a meson.build file alongside a Gemfile and a cmock.gemspec, so the CMock side can sit inside a Meson-based project, but the wiring between mock generation and your test targets is yours to write.

Getting CMock means a recursive clone or a zip with extra work

The getting started section gives three routes. Under Ceedling, nothing to do. Otherwise the simplest way is to grab it from GitHub, and the README notes the recursive flag is needed:

    > git clone --recursive https://github.com/throwtheswitch/cmock.git

The submodule flag matters because the repository carries a .gitmodules file and a vendor directory, so a shallow non-recursive clone leaves you without the bundled dependencies. The third route is downloading the zip file from GitHub, and here the README warns that you will also need to grab your own copy of Unity and CException, because GitHub does not bake dependencies into the zip files. That is a small but real trap for a team setting up CI from a tarball, because the failure appears as a missing header at build time rather than as an obvious download step. There is also a RubyGems route implied by the gemspec and the Gemfile, though the README does not spell it out as one of the three numbered options.

Running the self tests is the way to check your setup

CMock ships with its own test suite, and the README suggests running it both as a way to contribute and as a way to verify that it can perform its self tests on your system. The sequence is short, and it needs RubyGems present:

    > cd cmock
    > bundle install   # Ensures you have all RubyGems needed
    > cd test
    > rake             # Run all CMock self tests

The bundle install step is the one that will fail first on a fresh machine, since it resolves the gems in the Gemfile, and the rake invocation then runs the whole suite rather than a filtered subset. This is a useful check before you wire CMock into a project, because a self test failure tells you your Ruby or C toolchain is not what the project expects, rather than leaving you to debug your own generated mocks. The repository also carries a CI workflow badge for the main workflow, and a .github directory for the workflow definitions.

No documentation of a standalone generation command

The gap in the documentation is worth naming. The README explains how to obtain CMock, how to run its self tests, and where the examples and the summary document are, but it does not document the command line you run to turn a header into a mock. The generation entry point, the configuration options and the naming rules for the generated files are not described there, and the config directory in the repository is where those defaults live. The summary document, docs/CMock_Summary.md, is listed as the first resource for anyone not sure what they are doing, so that is where the configuration model is meant to be explained. The practical consequence for an evaluation is that you cannot assess the generated-code contract, the naming conventions, or how the runtime verifies call order and arguments, from the README alone. Plan to read docs/CMock_Summary.md and the example projects before deciding, because those are the artefacts that show what the mocks look like in practice.

MIT licensed, with a release history that has a long middle

The licence is MIT, and the README points readers at docs/license.txt for the MIT licence text. The project is not archived and the last push was on 2026-10-17, so work is landing. The release tags tell a different story about cadence. v2.5.3 is dated 2021-01-29, v2.6.0 is dated 2025-01-01, and v2.7.0 is dated 2026-07-16. That is a four year gap and then a twenty month gap, with the current line moving more recently than the tag history alone would suggest. For a tool that generates code you commit or build, that matters in one specific way: a change in the generator can change the code your tests compile against, so the version of CMock is part of your build's identity. Pin it, and read docs/CMockChangeLog.md when you move it. The maintained documentation set is small and pointed, with the summary, the known issues list, the change log, the contributing guidelines in docs/CONTRIBUTING.md and a developer portal on ThrowTheSwitch.org.

Editorial conclusion

Adopt CMock if you are unit testing C, you already want Unity as the test framework, and you are prepared to keep Ruby in the build toolchain, either directly or through Ceedling. Do not adopt it if you need a self-contained C-only test build, because the zip distribution does not bake in Unity and CException, and the generator itself is a Ruby gem with a Gemfile and a gemspec. Before you commit, read docs/CMockKnownIssues.md, decide whether Ceedling will own your unit testing builds or you will drive CMock directly, and confirm the mock expectations and stub behaviour match what your test style needs.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ThrowTheSwitch/CMock on GitHub