Documentation for 3.10
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
It is also possible that configurations can add new Interactive Actions to the GUI (static or dynamic). It has been found occasionally useful to allow this module to be different from the module indicated by config_module so that configuring the GUI can be done independently of configuring the procedure for selecting and running tests. This is done via the config file entry “interactive_action_module”, which will default to the value of “config_module” if not explicitly defined.
To be continued: with documentation of the configuration module API...

Last updated: 05 October 2012