The most important rule to follow when writing testing samples is:
This motto means that testing samples must be written with the same strictness as real programs are written. In particular, you should avoid “shortcuts” and simplifications.
Don't just play with the preprocessor if you want to prepare a compilation. For instance, using cpp to check whether a header is functional might let your configure accept a header which causes some compiler error. Do not hesitate to check a header with other headers included before, especially required headers.
Make sure the symbols you use are properly defined, i.e., refrain from simply declaring a function yourself instead of including the proper header.
Test programs should not write to standard output. They
should exit with status 0 if the test succeeds, and with status 1
otherwise, so that success
can be distinguished easily from a core dump or other failure;
segmentation violations and other failures produce a nonzero exit
status. Unless you arrange for exit
to be declared, test
programs should return
, not exit
, from main
,
because on many systems exit
is not declared by default.
Test programs can use #if
or #ifdef
to check the values of
preprocessor macros defined by tests that have already run. For
example, if you call AC_HEADER_STDBOOL
, then later on in
configure.ac you can have a test program that includes
stdbool.h conditionally:
#ifdef HAVE_STDBOOL_H # include <stdbool.h> #endif
Both #if HAVE_STDBOOL_H
and #ifdef HAVE_STDBOOL_H
will
work with any standard C compiler. Some developers prefer #if
because it is easier to read, while others prefer #ifdef
because
it avoids diagnostics with picky compilers like GCC with the
-Wundef option.
If a test program needs to use or create a data file, give it a name that starts with conftest, such as conftest.data. The configure script cleans up by running ‘rm -f -r conftest*’ after running test programs and if the script is interrupted.