Gist of the Day: Automated Testing With CUnit

It’s no secret that I love automated testing. I have done automated testing in Perl, C, Java, JavaScript, C++, Python, Objective-C, and PHP. I have yet to find an automated testing framework I didn’t like. C is a unique case since it requires a little more cleverness to perform some of the normal control techniques that you can do with other frameworks.

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).

Why CUnit?

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.

The Demo

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=””]
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”]

The Conclusion

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:

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.