WTF is a control technique you ask? A control technique is a method by which you control your test by factoring out a portion of the program which has side-effects outside the scope or control of the code you are intending to test. Sometimes this means mocking a function, other times this could mean using fixture data. As with all testing, however, this is a cause for creativity and cleverness and not for choosing not to test (there is very seldom a good reason not to test, and if you think you found a good reason not to test then you are most likely mistaken).
Well, CUnit is useful because it has all of the basic functionality you expect in a test framework: suites, cases, assertion methods, and then an overall framework to tie it all together. Also, it is freely available and very simple to use.
Caution: This is a very brief demo
I’m only going to dip my feet into the waters of CUnit here, I mainly want to give you a demonstration of how to use it a very basic level. Keep in mind that this is C, and that there is a little bit more boiler-plate type code involved.
Here’s the code I have for you today:
[gist id=”6429992″ file=”cunit_demo.c”]
And because it might help, here’s the build script:
[gist id=”6429992″ file=”build.sh”]
Like most testing frameworks, CUnit has the concept of a cleanup and a setup routine. This is the first thing we do is define functions for those. After that, you see where I define a test. The test here is pretty straight-forward, testing that for two C strings, you
strcpy() into the C string and then call the
CU_ASSERT_STRING_EQUAL() macro. This macro tests for string equality.
After the test function you see the
main() function. In main I first initialize the suite, and then right away I start adding tests to the suite. After I’m done adding tests I call
CU_basic_set_mode(CU_BRM_VERBOSE) to tell the test framework to use basic mode, and to set the output to verbose (this way my output comes out, too).
The call to
CU_basic_run_suite() actually causes the framework to execute the tests. After we run we call
CU_basic_show_failures(CU_get_failure_list()) just to output all of the test failure. From there on everything else is cleanup.
Here’s the output of the test program:
[gist id=”6429992″ file=”output”]
I find CUnit to be very useful. I use it at work and at home for a couple of different things. I know this demo was super short, but I have two links I think will help you see how CUnit is used in one of my simple pieces of code, and then I’ll link you directly to the framework:
- Here’s my libmanchicken library’s test directory: https://github.com/manchicken/libmanchicken/tree/master/t
- Here’s the test framework itself: http://cunit.sourceforge.net/
I know that this demo was short, I’ve been keeping them shorter since so many people wanted write-ups as well. This is a fun project that I’ve been doing, but I have been spending about one-to-two hours per day on it. I really hope you find it useful.