Documentation for 3.12
Other versions: trunk  3.27  3.26  3.25  3.24  3.23  3.22  3.21  3.20  3.19  3.18  Older...

Using TextTest as a Python Framework: Writing your own config module

Right now this is fairly restricted and is lifted and updated from the old user guide, which I've removed. This document will be improved and extended when I'm finished with higher priority stuff.
Configuration Modules
TextTest (as a standalone tool) consists of a core framework, which interprets a directory structure and the files in it a certain way, and the default configuration module , which is responsible for actually doing things (like running tests and evaluating the results). This default configuration comes with TextTest and is used unless you specify otherwise. But it is possible to override it with your own configuration and so tweak what it does. This allows you to take advantage of local circumstances: for example to plug in custom reporting tools for your application, or to take advantage of locally installed software. It also provides a way for you to add your own experimental features to TextTest without making it difficult to upgrade. Naturally, doing this involves writing code in Python.
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.
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.
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.
Interactive Action Modules
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 module.
The CVS plugin is the only such module provided with the download apart from the default, this can be enabled by setting
which will provide an extra menu for checking CVS information for your tests.
To be continued: with documentation of the configuration module API...

Last updated: 05 October 2012