The testsuite.at is a Bourne shell script making use of special
Autotest M4 macros. It often contains a call to
its beginning followed by one call to
m4_include per source file
for tests. Each such included file, or the remainder of
testsuite.at if include files are not used, contain a sequence of
test groups. Each test group begins with a call to
then an arbitrary number of shell commands or calls to
and then completes with a call to
AT_CLEANUP. Multiple test
groups can be categorized by a call to
All of the public Autotest macros have all-uppercase names in the namespace ‘^AT_’ to prevent them from accidentally conflicting with other text; Autoconf also reserves the namespace ‘^_AT_’ for internal macros. All shell variables used in the testsuite for internal purposes have mostly-lowercase names starting with ‘at_’. Autotest also uses here-document delimiters in the namespace ‘^_AT[A-Z]’, and makes use of the file system namespace ‘^at-’.
Since Autoconf is built on top of M4sugar (see Programming in M4sugar) and M4sh (see Programming in M4sh), you must also be aware of those namespaces (‘^_?\(m4\|AS\)_’). In general, you should not use the namespace of a package that does not own the macro or shell code you are writing.
Initialize Autotest. Giving a name to the test suite is encouraged if your package includes several test suites. Before this macro is called,
AT_PACKAGE_BUGREPORTmust be defined, which are used to display information about the testsuite to the user. Typically, these macros are provided by a file package.m4 built by make (see Making testsuite Scripts), in order to inherit the package name, version, and bug reporting address from configure.ac.
The copyright-notice shows up in both the head of testsuite and in ‘testsuite --version’.
Autotest test suites rely on PATH to find the tested program. This avoids the need to generate absolute names of the various tools, and makes it possible to test installed programs. Therefore, knowing which programs are being exercised is crucial to understanding problems in the test suite itself, or its occasional misuses. It is a good idea to also subscribe foreign programs you depend upon, to avoid incompatible diagnostics.
This macro identifies the start of a category of related test groups. When the resulting testsuite is invoked with more than one test group to run, its output will include a banner containing test-category-name prior to any tests run from that category. The banner should be no more than about 40 or 50 characters. A blank banner will not print, effectively ending a category and letting subsequent test groups behave as though they are uncategorized when run in isolation.
This macro starts a group of related tests, all to be executed in the same subshell. It accepts a single argument, which holds a few words (no more than about 30 or 40 characters) quickly describing the purpose of the test group being started. test-group-name must not expand to unbalanced quotes, although quadrigraphs can be used.
Associate the space-separated list of keywords to the enclosing test group. This makes it possible to run “slices” of the test suite. For instance, if some of your test groups exercise some ‘foo’ feature, then using ‘AT_KEYWORDS(foo)’ lets you run ‘./testsuite -k foo’ to run exclusively these test groups. The title of the test group is automatically recorded to
Several invocations within a test group accumulate new keywords. In other words, don't fear registering the same keyword several times in a test group.
Make the test group fail and skip the rest of its execution, if shell-condition is true. shell-condition is a shell expression such as a
testcommand. Tests before AT_FAIL_IF will be executed and may still cause the test group to be skipped. You can instantiate this macro many times from within the same test group.
You should use this macro only for very simple failure conditions. If the shell-condition could emit any kind of output you should instead use AT_CHECK likeAT_CHECK([if shell-condition; then exit 99; fi])
so that such output is properly recorded in the testsuite.log file.
Determine whether the test should be skipped because it requires features that are unsupported on the machine under test. shell-condition is a shell expression such as a
testcommand. Tests before AT_SKIP_IF will be executed and may still cause the test group to fail. You can instantiate this macro many times from within the same test group.
You should use this macro only for very simple skip conditions. If the shell-condition could emit any kind of output you should instead use AT_CHECK likeAT_CHECK([if shell-condition; then exit 77; fi])
so that such output is properly recorded in the testsuite.log file.
Determine whether the test is expected to fail because it is a known bug (for unsupported features, you should skip the test). shell-condition is a shell expression such as a
testcommand; you can instantiate this macro many times from within the same test group, and one of the conditions is enough to turn the test into an expected failure.
Initialize an input data file with given contents. Of course, the contents have to be properly quoted between square brackets to protect against included commas or spurious M4 expansion. The contents must end with an end of line. file must be a single shell word that expands into a single file name.
Execute a test by performing given shell commands. commands is output as-is, so shell expansions are honored. These commands should normally exit with status, while producing expected stdout and stderr contents. If commands exit with unexpected status 77, then the rest of the test group is skipped. If commands exit with unexpected status 99, then the test group is immediately failed. Otherwise, if this test fails, run shell commands run-if-fail or, if this test passes, run shell commands run-if-pass.
This macro must be invoked in between
If status is the literal ‘ignore’, then the corresponding exit status is not checked, except for the special cases of 77 (skip) and 99 (hard failure). The existence of hard failures allows one to mark a test as an expected failure with
AT_XFAIL_IFbecause a feature has not yet been implemented, but to still distinguish between gracefully handling the missing feature and dumping core. A hard failure also inhibits post-test actions in run-if-fail.
If the value of the stdout or stderr parameter is one of the literals in the following table, then the test treats the output according to the rules of that literal. Otherwise, the value of the parameter is treated as text that must exactly match the output given by commands on standard out and standard error (including an empty parameter for no output); any differences are captured in the testsuite log and the test is failed (unless an unexpected exit status of 77 skipped the test instead). The difference between
AT_CHECK_UNQUOTEDis that only the latter performs shell variable expansion (‘$’), command substitution (‘`’), and backslash escaping (‘\’) on comparison text given in the stdout and stderr arguments; if the text includes a trailing newline, this would be the same as if it were specified via an unquoted here-document. (However, there is no difference in the interpretation of commands).
- The content of the output is ignored, but still captured in the test group log (if the testsuite is run with option -v, the test group log is displayed as the test is run; if the test group later fails, the test group log is also copied into the overall testsuite log). This action is valid for both stdout and stderr.
- The content of the output is ignored, and nothing is captured in the log files. If commands are likely to produce binary output (including long lines) or large amounts of output, then logging the output can make it harder to locate details related to subsequent tests within the group, and could potentially corrupt terminal display of a user running testsuite -v.
- For the stdout parameter, capture the content of standard output to both the file stdout and the test group log. Subsequent commands in the test group can then post-process the file. This action is often used when it is desired to use grep to look for a substring in the output, or when the output must be post-processed to normalize error messages into a common form.
- Like ‘stdout’, except that it only works for the stderr parameter, and the standard error capture file will be named stderr.
- Like ‘stdout’ or ‘stderr’, except that the captured output is not duplicated into the test group log. This action is particularly useful for an intermediate check that produces large amounts of data, which will be followed by another check that filters down to the relevant data, as it makes it easier to locate details in the log.
- For the stdout parameter, compare standard output contents with the previously created file expout, and list any differences in the testsuite log.
- Like ‘expout’, except that it only works for the stderr parameter, and the standard error contents are compared with experr.