There may be useful existing procedures already written for your test in the `lib' directory of the DejaGnu distribution. See section DejaGnu procedures.
It is safest to write patterns that match all the output
generated by the tested program; this is called closure. If a
pattern does not match the entire output, any output that remains will
be examined by the next expect command. In this
situation, the precise boundary that determines which expect
command sees what is very sensitive to timing between the expect
task and the task running the tested tool. As a result, the test may
sometimes appear to work, but is likely to have unpredictable results.
(This problem is particularly likely for interactive tools, but can also
affect batch tools--especially for tests that take a long time to finish.)
The best way to ensure closure is to use the `-re' option for the
expect command to write the pattern as a full regular
expressions; then you can match the end of output using a `$'. It
is also a good idea to write patterns that match all available output by
using `.*\' after the text of interest; this will also match any
intervening blank lines. Sometimes an alternative is to match end of
line using `\r' or `\n', but this is usually too dependent on
terminal settings.
Always escape punctuation, such as `(' or `"', in your patterns; for example, write `\('. If you forget to escape punctuation, you will usually see an error message like `extra characters after close-quote'.
If you have trouble understanding why a pattern does not match the
program output, try using the `--debug' option to runtest,
and examine the debug log carefully. See section Logging expect internal actions.
Be careful not to neglect output generated by setup rather than by the
interesting parts of a test case. For example, while testing GDB,
I issue a send `set height 0\n' command. The purpose is simply to
make sure GDB never calls a paging program. The `set height'
command in GDB does not generate any output; but running any
command makes GDB issue a new `(gdb) ' prompt. If there were
no expect command to match this prompt, the output `(gdb) '
begins the text seen by the next expect command--which might
make that pattern fail to match.
To preserve basic sanity, I also recommended that no test ever pass if
there was any kind of problem in the test case. To take an extreme
case, tests that pass even when the tool will not spawn are misleading.
Ideally, a test in this sort of situation should not fail either.
Instead, print an error message by calling one of the DejaGnu procedures
error or warning.
Go to the first, previous, next, last section, table of contents.