16.1 testsuite Scripts

Generating testing or validation suites using Autotest is rather easy. The whole validation suite is held in a file to be processed through autom4te(4), itself using GNU m4 under the scene, to produce a stand-alone Bourne shell script which then gets distributed. Neither autom4te nor GNU m4 are not needed anymore at the installer end.

Each test of the validation suite should be part of some test group. A test group is a sequence of interwoven tests that ought to be executed together, usually because one test in the group creates data files than a later test in the same group needs to read. Complex test groups make later debugging more tedious. It is much better keeping keep only a few tests per test group, and if you can put only one test per test group, this is just ideal.

For all but the simplest packages, some file such as `testsuite.at' does not fully hold all test sources, as these are often easier to maintain in separate files. Each of these separate files holds a single test group, or a sequence of test groups all addressing some common functionality in the package. In such cases, file `testsuite.at' only initializes the whole validation suite, and sometimes do elementary health checking, before listing include statements for all other test files.

The validation scripts that Autotest produces are by convention called testsuite. When run, testsuite executes each test group in turn, producing only one summary line per test to say if that particular test succeeded or failed. At end of all tests, summarizing counters get printed. If any test failed, one debugging script gets automatically generated for each test group which failed. These debugging scripts are named `debug-nn.sh', using for nn the sequence number of the test group. In the ideal situation, none of the tests tests fail, and consequently, no debugging script is generated out of validation.

The automatic generation of debugging scripts for failed test has the purpose of easing the chase for bugs.

It often happens in practice that individual tests in the validation suite need to get information coming out of the configuration process. Some of this information, common for all validation suites, is provided through the file `atconfig', automatically created by AC_CONFIG_TESTDIR. For configuration informations which your testing environment specifically needs, you might prepare an optionnal file named `atlocal.in'. The configuration process produces `atconfig' and `atlocal' out of these two input files, and these two produced files are automatically read by the `testsuite' script.

Here is a diagram showing the relationship between files.

Files used in preparing a software package for distribution:

testsuite.at --> autom4te* --> testsuite

Files used in configuring a software package:

.-> atconfig / [atlocal.in] --> config.status* --< \ `-> [atlocal]

Files created during the test suite execution:

atconfig -->. .--> testsuite.log \ / >-- testsuite* --< / \ [atlocal] ->' `--> [debug-nn.sh*]