The easiest way to prepare a new test case is to base it on an existing one for a similar situation. There are two major categories of tests: batch or interactive. Batch oriented tests are usually easier to write.
The GCC tests are a good example of batch oriented tests. All
GCC tests consist primarily of a call to a single common procedure,
since all the tests either have no output, or only have a few warning
messages when successfully compiled. Any non-warning output is a test
failure. All the C code needed is kept in the test directory. The test
driver, written in expect, need only get a listing of all the C
files in the directory, and compile them all using a generic procedure.
This procedure and a few others supporting for these tests are kept in
the library module `lib/c-torture.exp' in the GCC test suite.
Most tests of this kind use very few expect features, and are
coded almost purely in Tcl.
Writing the complete suite of C tests, then, consisted of these steps:
expect procedures for
compilation.
glob for filename expansion with
wildcards) and call a Tcl procedure with each filename. It also checks
for a few errors from the testing procedure.
Testing interactive programs is intrinsically more complex. Tests for most interactive programs require some trial and error before they are complete.
However, some interactive programs can be tested in a simple fashion
reminiscent of batch tests. For example, prior to the creation of
DejaGnu, the GDB distribution already included a wide-ranging
testing procedure. This procedure was very robust, and had already
undergone much more debugging and error checking than many recent
DejaGnu test cases. Accordingly, the best approach was simply to
encapsulate the existing GDB tests, for reporting purposes.
Thereafter, new GDB tests built up a family of expect
procedures specialized for GDB testing.
`gdb.t10/crossload.exp' is a good example of an interactive test.
Go to the first, previous, next, last section, table of contents.