TextTest can be operated in two modes: interactive mode which expects a user to be present and able to respond, and batch mode which does not. Batch mode provides the test results in the form of an email and/or HTML report. This document aims to describe the various interactive modes.

Interactive mode now consists primarily of the PyGTK GUIs : the dynamic GUI, for monitoring tests as they run, and the static GUI, for examining and changing test suites and starting the dynamic GUI. The older console interface is still present, and documented briefly below, though it is no longer being actively developed.

It is thus possible to operate with TextTest in any of three ways: console only, dynamic GUI only (started from a command prompt for each test run) or static and dynamic GUIs. These possibilities have arisen in that order: TextTest was traditionally a command-line UNIX script, indeed the very early versions were actually Bourne shell scripts! It is generally best to pick one of these approaches and stick to it: they are more or less equivalent.

Newcomers to TextTest, unless opposed to GUIs in principle, should generally use both the static and dynamic GUIs. This is really how TextTest is meant to be used now (anyone on Windows will find any other way of operating painful, probably). It can still be useful to know about the other interfaces in case of problems: they can help in error-finding because they are simpler.

The “default_interface” config file setting can be used to choose your preferred way of running. It can take the values “static_gui”, “dynamic_gui” or “console”, and defaults to the first of these. Any interface can also be chosen on the command line, via the options -gx, -g or -con respectively.

Note also that there are many ways in which TextTest's appearance and default setup can be configured to suit your application or personal tastes. Find out how here.

This is started if the “-con” option is provided, or if “default_interface” is set to “console”. It is simpler and much more restricted than the GUIs.

Essentially, it will run each test in turn, and if it fails, will ask whether you wish to view the differences, approve it, or continue. Viewing the differences will write a (truncated) text version of all file differences to the standard output, and will start the graphical difference viewer on the file specified by the config file entry “log_file” (the standard output of the SUT, by default). Approving works much like from the dynamic GUI, except that there is no possibility to approve single files or multiple tests at the same time (but see below). Continuing will do nothing and leave everything in place.

There are a couple of command-line options relevant to the console interface only, both related to approving. Specifying “-o” will cause all files judged different to be overwritten (the equivalent of the GUI “Approve” button applied to all tests, except you have to decide before the run starts). The “-n” option will cause all files regarded as the same to be updated: a way of updating the run dependent text contained in them. Specifying both these options will cause all files to be updated, regardless of what happens.