Dave's Unit Test

Dave's Unit Test (DUT) is a simple unit testing infrastructure implemented in c-preprocessor macros and GNU make.

[SourceForge   Project page] [Getting and Using DUT] [Why Use DUT] [Plans for DUT] [DUT with multiple threads]

Features

• Test the (non-)equality of any types (including C++ classes) which can be assigned using the = operator, and compared using the == operator.
• Special purpose tests for the (non-)equality of floating point types allow for a user specified granularity in machine arithmetic.
• Built in string comparison tests.
• Able to test for the (non-)existence of C++ exceptions and to trap and report unexpected exceptions. (optional)
• Able to test for the (non-)existence of POSIX signals (i.e. signal (2)) and to trap and report on unexpected signals. (optional)
• Thread-saftey mechanism build on POSIX semaphores. (optional)

Dependencies

• You'll need a c or c++ compiler with a working preprocessor (if objective c or the like works for you, let me know!)
• You must be able to link the code you're testing with c or c++, and you can only test object files which do not define main()
• GNU make

Compatibility

DUT has been tested with (and only with) various versions of gcc. As of 1 March 2008, the SVN head works with tcc 0.9.23 as well, but not with nwcc 0.7.5. At this point I do not know if this is a fault in my code or in the compiler.

If you know that it does or especially does not work with another compiler, please let me know.

Testing with other compilers turned up a miscellaneous "compatibility" issue: the behaviour of various libc function on bad input is not always specified. So on my PowerBook G4 the code

char *str4 = NULL;
printf("%c\n",str4[0]);

Release History

Bugs, misfeatures, annoyances, and todos

• Failing the above, can we have the user pass a type, and generate the cache variable(s) in the scope of the test macro? Answer: this looks promising, and some test macros are in the SVN head. First release with 0.8.2 to become the standard in 0.9.0
• It would be nice to provide a set of higher level ASSERT_<type>_[N]EQUAL[_FATAL,_WARN] type macros ala xUnit.
• The documentation is badly organized. And incomplete. Getting better We need to more some of it out of README.dut, and offer a better packaged form of documentation.
• The lexical ordering of tests is inconvenient, and limits the scaling.
• The single list of object files to link to the test code, could cause trouble, and certainly makes more work for the linker.
• We shouldn't have to have only one type of test file always built with only one compiler (DUT_SRC_SUF and DUT_CC). WE want a way to build object files using default rules, or to let the user specify the object file build rules...
• Can the typeof() macro be used to eliminate the user passed cache variables? Is this portable? Answer: non-standad, non-portable, and not reliable.
• Can we wrap some code around the-bit-that-runs-the-tests-in-the-makefile to capture the output and redirect it to mailx or something?
• As of 0.8.2, DUT is not thread-safe (global storage is used to maintain test counts and the like). That is to say, you can not safely run tests in multiple threads (without providing locking, yourself), not that you can not test code fragments that you will use in a multi-threaded environment, or that you cannot use DUT to detect some violations of thread safety. We need to develop this idea, and provide demonstration on what can, and can not be done. Look for a portable locking solution that can be implemented in DUT. Possibly POSIX semaphores. In SVN head, optional of definition of _DUT_THREAD_SAFE_. Release with 0.8.3.

Want to help?

Good! Contact me.

Need help?

That's not so good, but OK.

Leave a bug report or feature request if appropriate, or contact me.