User Ratings

★★★★★
★★★★
★★★
★★
9
0
0
0
0
ease 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5 5 / 5
features 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5 5 / 5
design 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5 5 / 5
support 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5 4 / 5

Rate This Project
Login To Rate This Project

User Reviews

  • check is simply great.
  • I've used check for many years, and it was easy to compile and use from the very first version I tried, with my first tests up an running in minutes. It is now supported in most distro repositories, and is pretty much the defacto standard for unit testing C programs. Each test runs in a separate process (this can be turned off).
    1 user found this review helpful.
  • I could set it up easily, it was actually even in the apt-repository. It's a good UT library and I am helped very much by it.
    1 user found this review helpful.
  • Very fast to take in use. Something like 30 minutes from install to first tests up and running. This is exactly what one expects from a good UT framework - that it makes life easier, not more complicated. This one does.
    1 user found this review helpful.
  • Asserts print the _values_ of the variables when constraint is violated as well as source file/line-number (vs CUnit, which prints the names - useless info when you already are shown the line number). Handles seg faults etc by forking the test, but has mode to suppress the fork (so you can run the test in gdb and see what is happening). Documentation is a bit weak - highly recommend reading the check.h at least (in addition to the available docs) if not reading some of the source code. You'll discover useful stuff. Supports suites containing sets of test cases, suite of suites, separate setup/teardown functions per test case set, timeouts for dealing with infinite loops, mechanism for handling testing of signal handling, multiple levels of verbosity, logging in plain text and in XML. The tutorial uses Autoconf to configure, overly complex for a simple tutorial; the Autoconf setup failed on my platform (Ub 10.4 LTS), so I just grabbed the test sources and built a simple script to compile/run the sample. Tutorial also uses patch formatted blurbs to take the test sources from one step to the next. The step-at-a-time approach is nice but I'd rather see the whole source with new sections / changes highlighted at each step (it's HTML and adding a few tags here and there would be all that's needed). It would make the tutorial a lot easier to read esp. for those who are browsing and evaluating 'check' (because like me they are probably not going to take the time while browsing to actually run patch multiple times on several files to see how each looks). Or go first class - provide the source in subdirs, each at a particular step, and provide links to the files therein. That would be nice! The sample test also does not use or even mention the most useful capabilities such as ck_assert_int_eq() (which I use for most of my tests - it's the most common thing to check). It shows only fail_unless(), which I use much less frequently. I find unit tests are most useful if they pinpoint the issue and show the offending value rather than just spit out a string. ("Don't tell me it's wrong - show me exactly what is wrong.") Available as a pkg in Ubuntu BTW.
    1 user found this review helpful.
  • good job
  • excellent for writing robust test fw...
  • good unit testing framework for C programs
  • C unittesting, easy to use, tests in isolated process space. All Good Things.