In order to use a configuration other than the default one,
specify the "config_module" entry in your config file.
What this configuration will do is of course up to the person
who wrote it, and hence in order to find this information out
for a particular application, run "texttest -a <app>
-help". This provides a means for configurations to explain
how they differ from the default one.
If you write such a configuration module, the only requirement is that TextTest can import it,
so it must be placed somewhere on PYTHONPATH. An additional trick is that you can place it in the root of your
test suite in a directory called "texttest_config_modules", where it will also be picked up.
A configuration can both extend the range of command line
options available, and the config file entries that will be
interpreted and acted upon. Occasionally, they have defined new
sorts of files that define test cases and test suites, besides
the usual ones. It can
then be useful to have the static GUI display them as such, so
there is a config file entry “definition_file_stems”
to allow this to be configured. They can be keyed with "regenerate" if they
will also be produced by the program, like the default configuration's traffic and usecase files.
Unix-style file expansions may be used to indicate a range of possible stems.
TextTest comes with 2 configurations to choose from -
"default" which should work anywhere, and
"
queuesystem"
for use on UNIX with the
SGE
or
LSF
grid engine installed.
There is a similar mechanism for the GUIs, whereby new configurations
can extend the user interface to interface with some particular tool or environment. This is
controlled by the config file entry “interactive_action_module”, which will
default to the value of “config_module” with a "_gui" suffix added, if it is not
explicitly defined. Your starting point for these modules is therefore the default_gui/__init__.py module.