2006-03-08

Check, as most test frameworks, has the following hierarchy:

  main()
  |-- Suite1
  |   |--TestCase1
  |   |  |--TestA
  |   |  |--TestB
  |   |  |--TestC
  |   |  |--TestD
  |   |  `--TestE
  |   `--TestCase2
  |      |--TestF
  |      `--TestG
  `-- Suite2
      `--TestCase1
         |--TestA
         |--TestB
         |--TestC
         |--TestD
         |--TestE
         |--TestF
         `--TestG

It's notable that the author choose to have a lot of Suites named after whatever it's testing (say, logging), with each having one TestCase named "Core". Sometimes there's a second or a third TestCase. Each testcase has multiple tests, mostly a dozen or so.

The author has a src and a tests directory. In the tests directory, there is one main file called check_check_main.c which contains one main() function. This function adds all suites and runs them. It knows about the suites because there is a header file called check_check.h contains all the test suites. Then there is a separate file for each suite, for example, check_check_msg.c contains one test suite and a dozen tests. It has the header file check_check.h and all necessary header files to test project code.

Notable differences with JUnit are:

• You code the test runner, while in JUnit you just define tests and run them with either an IDE plugin or on the commandline with your build tool.
• Files do not have a separate setup() and teardown(). It remains to be seen whether this isn't necessary.
• Since you code the runner yourself, a plugin for an IDE like Eclipse could be somewhat problematic. Users could code their tests but you'd have to parse for the name of the test suite and compile a testrunner yourself. That last step is where things could go wrong, but I might be negative.