Our tools Unity and CMock were written several years ago to fill a missing gap in testing C projects. We had developed the Ceedling build system, based on Ruby’s Rake. Nevertheless we—and more importantly our user base—would rather not have to use Rake, nor retrofit it into an existing Make build.
Well, we finally made it happen!
Gimme the goods!
In order to add Make build support to pull in Unity, CMock, and support for all of your tests, a few new scripts were added. Essentially, the primary script is used to generate an auxiliary Makefile. The makefile support is generated with the following command:
> make setup
Basically, this creates a subfolder in your build directory (
./build/test by default), and then puts the new auxiliary Makefile in that folder. Other subfolders are added for generated test suite runners, mocks and object files to keep all of the testing goodness isolated from the rest of your build.
The nice thing is that the test suite runners and mocks use make dependencies to trigger generation. Therefore, these files are only generated when needed and have appropriate dependencies to cause them to be regenerated if the appropriate dependencies change.
In order to build and run all of the tests that were found in your project, you execute the following:
> make test
All tests will be executed, whether or not they fail, and a report summarizing the results of all of your tests will be printed out at the end.
Additionally, you can ask for a report at any time by running:
> make test_summary
We have added a new barebones example in the repo. Once you have the latest CMock repo on your machine, navigate to examples/make_example and follow the instructions below to try out the test project.
To build it, simply execute the following command to generate the Make support and build and run the tests:
> make setup; make test
Dependency Update Mechanism
Currently, the CMock make support requires the make setup command to be run whenever a given test adds new dependencies, which are conveniently specified by simply #include-ing the real header or mock header in a given test.
Furthermore, in order to get the updated make support, you must rerun make in a separate session. This means you need to perform the following upon changes in order to account for new test suites and dependencies:
> make setup; make test
We hope to be able eliminate this extra invocation of make in the future, but this is how things work for now.
Module and Test-suite Pairing
This initial version covers the most common use case for unit testing. Basically, it assumes that if you have a test file named
test_foo.c, there is a corresponding source module foo (comprised of foo.h and foo.c) that it will look in your source folder. It assumes all other modules #included in your test file are either mocks or supplied to the linker via the LDD_FLAGS variable which you must specify in your root project Makefile.
Again, we plan to add support for building and linking in any arbitrary modules as needed in order to allow integration testing in addition to interaction-based unit testing as well.
How do I get it?!?
Simply grab the latest CMock from Github using the instructions from the README. We also plan on making CMock a Ruby Gem as an alternate way to pull CMock onto your system as a shared package. More details to come!
Thanks for this! I’ve been happy with Ceedling, but some embedded people can get a little squeamish when you start talking about Ruby. I don’t necessarily think that’s warranted, but it can be a barrier to adoption nonetheless.
Comments are closed.