2006-03-01

< Check can also [http://check.sourceforge.net/doc/x232.html#AEN239 output XML], which is useful for reporting on nightly builds. I've created an XSLT to convert to HTML: [[check_unittest.xslt]]. It's very basic -- adjust to your needs.
< 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 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.