Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

file 130 lines (128 sloc) 7.277 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130
  <title>Check: A unit testing framework for C</title>
<h1>Check: A unit testing framework for C</h1>
<p>Check is a unit testing framework for C. It features a simple interface
for defining unit tests, putting little in the way of the developer.
Tests are run in a separate address space, so Check can catch both
assertion failures and code errors that cause segmentation faults or
other signals. The output from unit tests can be used within source
code editors and IDEs..</p>
<p>Check was inspired by similar frameworks that currently exist for
most programming languages; the most famous example being JUnit for
Java (<a href=""></a>). There is a
list of unit testing frameworks for multiple languages at <a
. Unit testing has a long history as part of formal quality assurance
methodologies, but has recently been associated with the lightweight
methodology called Extreme Programming. In that methodology, the
characteristic practice involves interspersing unit test writing with
coding (" test a little, code a little"). While the incremental unit
test/code approach is indispensable to Extreme Programming, it is also
applicable, and perhaps indispensable, outside of that methodology. </p>
<p>The incremental test/code approach provides three main benefits to
the developer:</p>
<p> </p>
  <li>Because the unit tests use the interface to the unit being
tested, they allow the developer to think about how the interface
should be designed for usage early in the coding process.</li>
  <li>They help the developer think early about aberrant cases, and
code accordingly.</li>
  <li>By providing a documented level of correctness, they allow the
developer to refactor (see <a href=""></a>
) aggressively.</li>
<p>That third reason is the one that turns people into unit testing
addicts. There is nothing so satisfying as doing a wholesale
replacement of an implementation, and having the unit tests reassure
you at each step of that change that all is well. It is like the
difference between exploring the wilderness with and without a good map
and compass: without the proper gear, you are more likely to proceed
cautiously and stick to the marked trails; with it, you can take the
most direct path to where you want to go.</p>
<p> </p>
<h2>Information about Check</h2>
<p>The Check project page is at <a
<p>The Check <a href="./doc/check_html/index.html">manual</a> contains a good tutorial introduction.
<p>This project has reached a point where it is fairly stable, and it
does the job well for people that use it. Therefore it is not that
actively maintained and long times may pass between checkins. It does
not mean that Check is some abandoned piece of unworking junk laying
around on SourceForge. We still aim for at least one release per year.
There are packages in Fedora and Debian, and probably several other
Project <a href="./NEWS">NEWS</a>, a summarized changelog.<br>
<h2>Getting Check</h2>
<p>Check can be dowloaded from <a
<p>The authors welcome any and all help with Check, whether through
enhancement requests, bug reports, patches, or documentation.&nbsp;
Mailing lists are preferred to forums as they're easier to
monitor.&nbsp; Please visit the Check project page at <a
<p>Patches to Check, unless trivial, should be against the latest SVN
trunk, and should include a full set of unit tests testing the new
behavior. No functionality goes into Check without unit tests, and
submitting a patch without automated testing guarantees that it will go
into the request queue, not the "to be applied soon" pool.<br>
<h2>Projects Using Check</h2>
We know of the following projects using Check:<br>
BitlBee: <a href=""></a><br>
checkmk: <a href=""></a><br>
ctrlproxy: <a href=""></a><br>
Daimonin: <a href=""></a><br>
DBMail: <a href=""></a><br>
Enlightenment (Eet and Eina libs): <a href=""></a><br>
EXIP: <a href=""></a><br>
Expat: <a href=""></a><br>
GNOME BuildBrigade: <a href=""></a><br>
GStreamer: <a href=""></a><br>
GNUpdf: <a href=""></a><br>
Iodine: <a href=""></a><br>
Lasso: <a href=""></a><br>
libspmt: <a href=""></a><br>
Loudmouth: <a href=""></a><br>
OpenSync (libopensync and libsyncml): <a href=""></a><br>
Pigment: <a href=""></a><br>
RedStore: <a href=""></a><br>
SCEW: <a href=""></a><br>
Tinymail: <a href=""></a><br>
XCB: <a href=""></a><br>

If you're using Check for an open source project and you're not listed
here, please subscribe to check-users AT, send
us an email, and we'll list you promptly.&nbsp; Particularly if the
first letter of your project is contained in the second half of the
alphabet! Please note that although it's easy for us to add your
project to our repository, the actual changes might not make it to the
website until we release the next version.<br>

<a href="./TODO">Current bugs and feature requests</a>.<br>
<h2>SVN access</h2>
See the project's <a href="">Subversion
page</a> for instructions.&nbsp; You do want to append '/trunk' to that
URL so that you don't end up checking out all tags and branches as
well.&nbsp; The CVS repository is now obsolete.<br>
$Date$ <br>
<a href=""><img
 alt="SourceForge Logo" border="0" height="31" width="88"></a>
Something went wrong with that request. Please try again.