| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 if a header is
functional might let your configure accept a header which will
cause some compiler error. Do not hesitate checking header with
other headers included before, especially required headers.
Make sure the symbols you use are properly defined, i.e., refrain for simply declaring a function yourself instead of including the proper header.
Test programs should not write anything to the standard output. They
should return 0 if the test succeeds, nonzero 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. Test programs should exit, not return, from
main, because on some systems (old Suns, at least) the argument
to return in main is ignored.
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_STDC, then later on in
`configure.ac' you can have a test program that includes an
ANSI C header file conditionally:
#if STDC_HEADERS # include <stdlib.h> #endif |
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 -rf conftest*'
after running test programs and if the script is interrupted.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |