Basic unit test and C, how do I get started?

You created a first test case. Now you need to create a test suite (a group of test cases) and a runner.

I would recommend you try to compile their example first to validate your environment, although their documentation introduces new code via diff (source patch) which I do not find very convenient.

If ever you decide to try with another framework (minunit came to my mind immediately), I can point you to a "tutorial".

I'd be more inclined to go with CUnit which is part of the X-Unit series of test frameworks.

It's scalable to large suites of tests and has been in use for many years, hence mature.

Any reason why you didn't go with CUnit?

HTH

cheers,

Rob

I've been using dejagnu for years and love it.

I started using it for embedded development because it supports very well the concept that the machine on which you're running the test program may be different than the machine on which you build the test program. A consequence of this is that testing code on multiple platforms is also well supported. Not sure if that's important. The gcc testsuite uses it. I use it for desktop development as well.

The basic idea with dejagnu is that you

• copy the test program to the "target" (which for local testing could be the ~/tmp directory)
• start the test program
• print stuff to the console (which acts as input to the test program)
• parse the output from the test program and match it with what you expect
• decide whether that output means pass or fail

Once you've got the test program and the test scripts written, you end up doing something like this:

$ runtest                === foo Summary ===# of expected passes            42foo-test built Thu Jan 15 20:09:19 PST 2009foo-test version 0.0.0.1runtest completed at Sun Jan 18 08:29:13 2009

The way I get there for testing a library named foo is:

• assume the source and include files for the library are in ~/src/foo
• create a directory named ~/src/foo/testsuite
• write a test program named foo-test.c that has a main() that
• processes command line args
• - prints a prompt and sits in a loop processing "commands" where I define a command to test each function in my library. This is sort of like a command shell but specific to the library. For something like my_pow I'd define the command to take 2 args.
• write a dejagnu (which is another layer on top of Expect (http://expect.nist.gov/, which is itself a layer on top of Tcl (http://www.tcl.tk/) function called my_pow that:
• takes two arguments
• calculates the expected result (in Tcl)
• sends "my_pow " to the console
• parses the output of the my_pow command from foo-test
• determines whether the actual result matches the expected result
• calls the appropriate dejagnu function (pass or fail)

Sounds hard, but it's not. It takes a little while to decide how much work to do in foo-test vs. how much to do in Tcl. I end up using a fair amount of shell (e.g. bash) functionality to do things like copy files to temp directories or look at the log files that my programs generate. So you end up getting good at all this stuff.

As far as references, there's one book on Expect that I'd say is a requirement for diving into this: http://oreilly.com/catalog/9781565920903/index.html.
Between that and an online Tcl command reference http://www.tcl.tk/man/tcl8.4/TclCmd/contents.htm and FAQ (http://www.psg.com/~joem/tcl/faq.html), you're pretty much there.

Good luck.

-DB