autoconf/tests
2000-11-28 19:11:24 +00:00
..
.cvsignore Added at-setup-line. 2000-11-28 19:11:24 +00:00
aclocal.m4 * tests/aclocal.m4 (AC_ENV_SAVE): Rename to ... 2000-10-25 11:47:20 +00:00
atconfig.in * tests/atconfig.in: Move code into... 2000-11-23 09:54:16 +00:00
atgeneral.m4 * tests/atconfig.in: Move code into... 2000-11-23 09:54:16 +00:00
atspecific.m4 Have the test suite list of the test groups and their references. 2000-11-23 09:53:52 +00:00
base.at * tests/atgeneral.m4 (AT_CLEAN_FILE_IFELSE, AT_CLEANUP_FILE) 2000-11-23 09:52:35 +00:00
compile.at Reorder the test suite so that low level features are tested 2000-11-16 14:56:17 +00:00
m4sh.at * tests/atgeneral.m4 (AT_CLEAN_FILE_IFELSE, AT_CLEANUP_FILE) 2000-11-23 09:52:35 +00:00
m4sugar.at Move Autotest on top of M4sh. 2000-11-23 09:45:48 +00:00
Makefile.am Move divert and undivert into m4_. 2000-11-23 09:46:48 +00:00
Makefile.in Move divert and undivert into m4_. 2000-11-23 09:46:48 +00:00
mktests.sh * aclang.m4 (ac_cv_prog_gcc, ac_cv_prog_gxx, ac_cv_prog_g77): 2000-11-07 14:16:54 +00:00
README Improve tests/README. 2000-11-02 14:36:16 +00:00
semantics.at * tests/atgeneral.m4 (AT_CLEAN_FILE_IFELSE, AT_CLEANUP_FILE) 2000-11-23 09:52:35 +00:00
suite.at Have the test suite list of the test groups and their references. 2000-11-23 09:53:52 +00:00
syntax.at * acspecific.m4 (AC_SYS_LARGEFILE): Don't worry about 2000-11-14 16:01:05 +00:00
tools.at * tests/atgeneral.m4 (AT_CLEAN_FILE_IFELSE, AT_CLEANUP_FILE) 2000-11-23 09:52:35 +00:00
torture.at * tests/atgeneral.m4 (AT_CLEAN_FILE_IFELSE, AT_CLEANUP_FILE) 2000-11-23 09:52:35 +00:00
update.at m4_syscmd was reestablished as syscd' intead of syscmd' because 2000-11-07 11:49:35 +00:00

							-*- outline -*-

This directory holds the M4sugar, M4sh and Autoconf test suites.


Here are a few rules on how to write tests.

* Order of the tests

It is extremely important to pay attention to the order of the tests.
There are basically two philosophies: (i) test earlier the most
critical features (hence hurried users will at least check those), or
(ii) test earlier the primitives.

For having tried both, I definitely recommend (ii).  In practice users
will run the whole test suite even if it's long.  And if they don't,
there will be enough other users who will do the job.

But also in practice some problems in the core of project can be
responsible for an incredible number of failures.  Then the problems
at the origin will be hidden by the consequences.  If dependencies are
properly ordered in the test suite (test features which depend upon
other features *after* having checked the latter), basically you'll
just have to pay attention to the first failures.  BTW, it also makes
`./testsuite -e' much more useful.


* Write tests!

Don't let you be bitten three times by the same dog!  When you spent a
significant amount of time tracking the failure of feature in some
more primitive problem, immediately write a test for the latter.

If you track down several bugs down to the same origin, write a test
especially for it.

Of course in both cases, more primitive tests will be run beforehand.
Write your test and have it failed before your fixing, and succeeding
after.  This usually means having at hand two copies of the source
tree, one running the test suite to have it fail, and the other to
have the same testsuite succeed.


* Autoconf

** Use of `exit'
Don't directly `exit 1' or `exit 77', rather use `AC_MSG_ERROR'.
First of all because when we have to read the test suite logs we are
happy to know why `configure' exited thanks to the error
message. Secondly, because `configure' traps the `exit' and pretty
many shells fail to set $? to 77 when trapping `exit 77'.  This
results in the test suite not being able to check the exit status.

** AC_MSG_ERROR
Of course, since macro names are forbidden in `configure', if you
really want to mention the macro name, you'll have to do without
including `A?_' in the output.