Unit testing in C

Check Tutorial
Prev |  | Next

# Chapter 2. Unit testing in C

The approach to unit testing frameworks used for Check originated with Smalltalk, which is a late binding object-oriented language supporting reflection. Writing a framework for C requires solving some special problems that frameworks for Smalltalk, Java or Python don't have to face. In all of those language, the worst that a unit test can do is fail miserably, throwing an exception of some sort. In C, a unit test is just as likely to trash its address space as it is to fail to meet its test requirements, and if the test framework sits in the same address space, goodbye test framework. To solve this problem, Check uses to fork system call to create a new address space in which to run each unit test, and then uses message queues to send information on the testing process back to the test framework. That way, your unit test can do all sorts of nasty things with pointers, and throw a segmentation fault, and the test framework will happily note a unit test error, and chug along.

The Check framework is also designed to play happily with common development environments for C programming. The author designed Check around Autoconf/Automake (thus the name Check -- make check is the idiom used for testing with Autoconf/Automake), and the test failure messages thrown up by Check use the common idiom of filename:linenumber:message used by gcc and family to report problems in source code. With (X)Emacs, the output of Check allows one to quickly navigate to the location of the unit test that failed; presumably that also works in VI and IDEs.

# 2.1. Other unit testing frameworks for C

The author knows of the following additional unit testing frameworks for C:

GNU Autounit

  Much along the same lines as Check, including forking to run unit tests in a separate address space (in fact, the author of Check stole the idea from GNU Autounit). GNU Autounit uses GLib extensively, which means that linking and such need special options, but this may not be a big problem to you, especially if you are already using GTK or GLib. See http://www.recursism.com/s2004/zp/products/gnu+autounit.

cUnit

  Also uses GLib, but does not fork to protect the address space of unit tests. See http://people.codefactory.se/~spotty/cunit/.

CUnit

  Standard C, with plans for an Win32 GUI implementation. Does not currently fork or otherwise protect the address space of unit tests. In early development. See http://cunit.sourceforge.net.

It is the author's considered opinion that forking or otherwise trapping and reporting signals is indispensable for unit testing (but it probably wouldn't be hard to add that to cUnit or CUnit). Try 'em all out: adapt this tutorial to use all of the frameworks above, and use whichever you like. Contribute, spread the word, and make one a standard. Languages such as Java and Python are fortunate to have standard unit test frameworks; it would be desirable that C have one as well.

Prev | Home | Next
Introduction |  | Tutorial: Basic unit testing