From: cpickett Date: Fri, 13 Oct 2006 06:02:34 +0000 (+0000) Subject: * Updated website. X-Git-Tag: 0.10.0~806 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=1e83fa5153f666b0a8e64ef6651d2c1d0cd2eac7;p=check * Updated website. git-svn-id: svn+ssh://svn.code.sf.net/p/check/code/trunk@350 64e312b2-a51f-0410-8e61-82d0ca0eb02a --- diff --git a/website/index.html b/website/index.html index 3f067a6..f6405d7 100644 --- a/website/index.html +++ b/website/index.html @@ -1,220 +1,99 @@ - - - Check: A unit test framework for C - - -

Check: A unit test framework for C

- -

Check is a unit test 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..

- -

Check was inspired by similar frameworks that currently exist - for most programming languages; the most famous example being - JUnit for Java (www.junit.org). There - is a list of unit test frameworks for multiple languages at www.xprogramming.com/software.htm - . 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. - -

The incremental test/code approach provides three main benefits - to the developer:

- -

    -
  1. 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.
    2. - -
  2. They help the developer think early about aberrant cases, - and code accordingly.
    3. - -
  3. By providing a documented level of correctness, they allow - the developer to refactor (see www.refactoring.com ) - aggressively.
    4. - -
- -

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.

- -

Information about Check

- -

Look at the Check homepage for the latest - information on Check: http://check.sourceforge.net -

- -

The Check project page is at http://sourceforge.net/projects/check/ -

- -

A tutorial introduction to Check can be found here.

- -

Getting Check

-

Check can be dowloaded from here.

- -

Contributing

- -

The author welcomes any and all help with Check, whether - through enhancement requests, bug reports, patches, documentation, - etc. Please visit the Check project page at http://sourceforge.net/projects/check/

- -

Patches to Check, unless trivial, should be against latest CVS, - 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.

- -

TODO

- - The following enhancements are being considered for Check. Please - let the author know if you would like to assist in any of these, - or if you would like to suggest additional enhancements: - - - - -

CVS access

-

To contribute to Check, you should download the source through - anonymous CVS, following these simple instructions:

- -
    -
  1. Navigate to the directory below which you want the new check - directory to be formed. That is, if you navigate to - /home/luser/foo/bar, the check files will be in - /home/luser/foo/bar/check.
    2. - -
  2. Issue the following command to login to CVS. When prompted - to supply the anonymous password, simply hit return. -
    -
    -$ cvs -d:pserver:anonymous@cvs.check.sourceforge.net:/cvsroot/check login
-
    -
    -
    3. -
  3. Issue the following command to setup the check subdirectory -
    -
    -$ cvs -z3 -d:pserver:anonymous@cvs.check.sourceforge.net:/cvsroot/check co check
-
    -
    -
    4. - -
  4. To keep current with CVS, use the following command within the -check directory -
    -
    -$ cvs -z3 update -dP 
-
    -
    - -

    Note that you do not have to supply the server directory - path or the user name (it is all kept in the CVS local - directory.) -

    5. -
- -

From that point on, using Check should simply be a matter of - the standard: -

-

- 
-$ ./configure
-$ make
-$ make install
-
-
-

Of course, since Check comes with its own unit tests, you can (and should) - substitute "make check" for "make" in the above.

- - SourceForge Logo - - + + + Check: A unit test framework for C + + +

Check: A unit test framework for C

+

Check is a unit test 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..

+

Check was inspired by similar frameworks that currently exist for +most programming languages; the most famous example being JUnit for +Java (www.junit.org). There is a +list of unit test frameworks for multiple languages at www.xprogramming.com/software.htm +. 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.

+

The incremental test/code approach provides three main benefits to +the developer:

+

+
    +
  1. 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.
    2. +
  2. They help the developer think early about aberrant cases, and +code accordingly.
    3. +
  3. By providing a documented level of correctness, they allow the +developer to refactor (see www.refactoring.com +) aggressively.
    4. +
+

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.

+

+

Information about Check

+

The Check project page is at http://sourceforge.net/projects/check/ +

+

A tutorial introduction to Check can be found here.
+

+

This project is at the moment only sporadically maintained, but it +works well and there are packages in Fedora and Debian.
+

+

Getting Check

+

Check can be dowloaded from here.

+

Contributing

+

The authors welcome any and all help with Check, whether through +enhancement requests, bug reports, patches, or documentation.  +Mailing lists are preferred to forums as they're easier to +monitor.  Please visit the Check project page at http://sourceforge.net/projects/check/
+

+

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

+

Projects Using Check

+We know of the following projects using Check:
+
+GStreamer: http://gstreamer.freedesktop.org/
+Expat: http://expat.sourceforge.net/
+GNOME BuildBrigade: http://live.gnome.org/BuildBrigade
+
+If you're using Check for an open source project and you're not listed +here, please subscribe to check-users@lists.sourceforge.net, send us an +email, and we'll list you promptly.
+

Todo
+

+Current bugs and feature requests.
+

SVN access

+See the project's Subversion +page for instructions.  You do want to append '/trunk' to that +URL so that you don't end up checking out all tags and branches as +well.  The CVS repository is now obsolete.
+--
+Last updated 2006-10-13 by cpickett.
+
+SourceForge Logo + +