This is the node for general QF-Test settings.

		Figure 29.2:  General options

Ask before closing (User)

When a test-suite or a test run-log has been modified, QF-Test asks whether it should be saved before it closes its main window. That query can be suppressed by turning off this option. Be warned that auto saving is not implemented yet, so you may lose data if you forget to save before closing.

Ask before overwriting (User)

When you try to save a test-suite or a run-log or generate a report, pgkdoc or testdoc over an existing file or directory, QF-Test asks for confirmation unless you turn off the option for the respective type of file.

Restore last session on startup (User)

If this option is set and QF-Test is opened in the workbench view, the previous session is restored by loading previously opened test-suites and selecting the previously selected node in each suite. If one or more test-suites are specified on the command line, this are loaded in addition to the previous session and receive the initial focus on startup.

Discard empty suite after loading (User)

A common situation in daily work is that a test-suite is loaded right after starting QF-Test. In that case the initial empty test-suite is typically unwanted and even a burden. Setting this option will cause the initial suite to be closed automatically.

Number of recent files in menu (User)

The »File« menu offers quick access to recently used test-suites or run-logs. This option determines the maximum number of recent file entries in the menu.

Default script language for script nodes (User)

This option can be set to either "Jython" or "Groovy" and determines the default setting for the 'Script language' attribute of newly created 'Server script' or 'SUT script' nodes.

Default character encoding for Jython (System)

This option sets the default encoding for Jython scripts in 'Server script' and 'SUT script' nodes as well as the interactive Jython terminals for QF-Test and the SUT. The default encoding for standard Jython is 'ascii'. To ease migration and improve two-way-compatibility with older QF-Test versions, the default setting for QF-Test is 'latin-1'. You can also experiment with other settings that better suit your locale.

For background information please see http://docs.python.org/library/codecs.html.

Note This setting does not affect the encoding for Python modules in separate files. If you get an error that a module cannot be loaded because no encoding is declared, you probably need to add a line of the form

# coding: latin-1

close to the top of that file. Please see http://www.python.org/peps/pep-0263.html for details.

Use old-style GNU regexps (from before QF-Test version 3.1) (System)

Server or SUT script name: OPT_USE_GNU_REGEXP

Since version 3.1 QF-Test uses the standard Java regular expression syntax by default. In case this causes problems with regular expressions in older tests, you can switch back to using the GNU regexp package via this option. For further information about regular expressions please see section 36.4.

These options are used to configure various settings regarding editing in the tree or detail view.

		Figure 29.3:  Editing

Warn when modifying a test-suite that cannot be saved (User)

If saving test-suites is prohibited, for example when working without a license, QF-Test will warn you that you will not be able to save your changes when a test-suite is modified for the first time. Deactivating this option suppresses that warning.

Ask before implicitly accepting detail modifications (User)

A very common mistake made while editing a test-suite is to forget pressing OK after making changes in the detail view of a node before switching to some other node, running a test, etc. If that happens QF-Test can either accept the modified values automatically or ask for confirmation by popping up a dialog with the detail view. The following options are available:

Always

Don't accept values implicitly, always ask for confirmation.

Only if values are suspect or invalid

Try to accept values implicitly as long as they are valid and not suspect. Currently "being suspect" is defined as having leading or trailing whitespace which can lead to subtle problems which are very hard to locate.

Never

Accept all valid values implicitly without asking for confirmation.

This option doesn't change the effect of explicitly discarding your modifications with the Cancel button or by pressing [Escape].

Number of undo levels per suite (User)

This option lets you set the number of edits that can be undone in a test-suite or run-log.

Intelligent scrolling in trees (User)

The default methods for interacting with Swing trees are not ideal. Moving the selection around causes a log of unnecessary horizontal scrolling and Swing has the tendency to scroll trees to a position where little context is visible around the selected node.

Because tree navigation is essential for QF-Test, some of these methods are implemented differently to provide a more natural interface and to make sure that there is always enough context visible around the selected node. However, your mileage may vary, so if you don't like the alternative methods you can switch back to the default Swing way of things by deactivating this option.

Minimum font size (pt) (User)

This option lets you set the minimum font size (as point value) used within QF-Test. A change in this value becomes operative after restarting QF-Test.

Show line numbers in script nodes (User)

If this option is set, line numbers are shown in 'SUT script' and 'Server script' nodes.

3.1+Show affected steps after refactoring (User)

This option specifies whether a list of all adapted nodes should be shown after refactoring steps, like renaming a 'Procedure', a 'Dependency', a 'Package' a 'Test-case' a 'Test-set' or a component. It is also valid for showing the dialog after moving those nodes and for component ID changes after updating components.

3.4+Check references before deletion (User)

If this option is set, QF-Test searches for references of nodes before nodes will be deleted. If references can be found, they will be shown in a dialog.

Projects are a new feature that is currently under development and not yet activated. The respective options have no effect yet.

Here you can edit your bookmarks, a list of files and nodes that can be accessed quickly via the menu »File«-»Bookmarks«.

		Figure 29.4:  Bookmarks

Though you can also create new bookmarks manually, it is preferable to use the menu item »File«-»Add to bookmarks« to add a bookmark for a whole test-suite or run-log or to select »Add to bookmarks« in the context menu of a node in a test-suite to add a bookmark for this sepecific node.

The following options determine which external programs are called by QF-Test.

		Figure 29.5:  External tools options

External editor command (User)

Scripts can be edited in an external editor by pressing [Alt-Return] or by clicking the button above the text area. The contents of the text area are then saved to a temporary file and the external editor is run to edit that file. It is recommended to define a name for the script before opening it in the external editor (see also Warn when running external editor without file name). Otherwise a random number is chosen as file name, which makes it difficult to distinguish several scripts opened in the external editor.

Changes made to an external file are picked up automatically by QF-Test. Depending on your settings, you may get a warning message when this happens (see Warn when test-suite is changed by an external editor). In case you are tempted to edit your script code parallel in the internal QF-Test editor: These changes are also saved in the temporary file. Editors like jEdit on their part are smart enough to detect the change and reload the file automatically.

This option determines the external editor command to use. There are two variants, the plain name of an executable file or a complex command including options. The latter is distinguished by the string $(file) which is the placeholder for the name of the temporary file. Additionally, $(line) may be used to pass the current line number to the editor as well.

Note The $(file)/$(line) syntax is used simply to avoid yet another different convention for variable attributes. No standard QF-Test $(...) variable expansion is taking place.

Plain commands need never be quoted. Examples are:

• emacsclient
• notepad
• C:\Program Files\Crimson Editor\cedt.exe

Complex commands on the other hand may need to use quotes, especially on windows. QF-Test takes care of quoting the $(file) argument itself:

• javaw.exe -jar C:\Programme\jEdit4.2\jedit.jar -reuseview $(file)
• "C:\Program Files\Crimson Editor\cedt.exe" $(file)
• xterm -e vi +$(line) $(file)

If this option is left empty, the value of the environment variable EDITOR is used, if it is defined when QF-Test is started.

Warn when test-suite is changed by an external editor (User)

Display a warning message when changes to a script made by an external editor are picked up by QF-Test (see also External editor command).

Warn when running external editor without file name (User)

Display a warning message when a script without name is opened in an external editor (see also External editor command).

External imaging program (User)

The 'Image' of a 'Check image' node can be edited in an external imaging program. The image is saved to a temporary PNG file and the external imaging program is run to edit that file. When finished editing, the file must be saved and the program exited. QF-Test will read the image back from the temporary file.

This option determines the program to use for the operation. There are two variants, the plain name of an executable file or a complex command including options. The latter is distinguished by the string $(file) which is the placeholder for the name of the temporary file.

Note The $(file)/$(line) syntax is used simply to avoid yet another different convention for variable attributes. No standard QF-Test $(...) variable expansion is taking place.

Plain commands need never be quoted. Examples are:

• gimp
• mspaint
• C:\Windows\System32\mspaint.exe

Complex commands on the other hand may need to use quotes, especially on windows. QF-Test takes care of quoting the $(file) argument itself:

• gimp --no-splash $(file)
• "C:\Windows\System32\mspaint.exe" $(file)

HTML browser (Unix only) (User)

On Unix systems this option allows you to set the HTML browser for the context sensitive help system. You can specify a complex command using '$url' as placeholder for the URL to show, e.g.
netscape -remote openURL($url)
or just a simple command like
firefox
in which case the URL is passed as the last argument. On Windows the system browser is used.

PDF reader (Unix only) (User)

On Unix systems this option allows you to set the program used to display PDF files. This is necessary to open the PDF manual from the »Help« menu. On Windows the program associated with the .pdf extension is used.

Unless told to do otherwise, QF-Test creates backups of existing files when saving test-suites or run-logs. These backup files are useful only in protecting against failures when saving a file. They are by no means a replacement for proper system backups. The following options determine if, when and how backup files are created.

		Figure 29.6:  Backup file options

Create backup files for test-suites (User)

Backup files for test-suites are created only if this option is activated. Please be careful and don't turn it off without a good reason, such as using a version control system for test-suites which obviates the need to create backups. Just think about the amount of work that goes into creating a useful test-suite and imagine the frustration if it gets destroyed accidentally.

Create backup files for test run-logs (User)

Usually a run-log is far less valuable than a test-suite, so there is a separate option that determines whether backups are created for run-logs.

Backup frequency (User)

There are two possibilities for the frequency with which backup files are created.

With the first option, "One backup per session", QF-Test creates a backup file only the first time a file is saved. If you continue editing the suite or run-log and save it again, the backup file is left unchanged. Only when you edit a different file or restart QF-Test, a new backup is created. This setting is useful is you keep only one backup per test-suite.

If, on the other hand, you keep multiple backups per suite, "Backup on every save" may be the preferred choice.

Name of the backup file (User)

Like many other things, the conventions for the names of backup files differ between Unix and Windows. While the common extension for a backup file under Windows is .bak, there are many variants under Unix. One of the most common is appending a tilde character '~'.

Number of backup files to keep (User)

You can keep more than one backup file for each test-suite or run-log. If you do so, backup files are named after the scheme .bak1, .bak2... for the .bak naming style and ~1~, ~2~... for the other. The most recent backup is always numbered 1. When a new backup is created, the old number 1 is renamed to 2, 2 renamed to 3 and so on. When the maximum is reached, the oldest files are deleted.

Auto-save interval (s) (User)

Interval after which a modified test-suite is saved automatically. Setting this value to 0 will disable auto-saving. Otherwise values less than about 20 seconds are not useful. Run-logs are never saved automatically. Auto-save files are created in the same directory as the test-suite or - in the case of new suites that have never been saved - in the directory .qftest under the user's home directory.

		Figure 29.7:  Library path option

Directories holding test-suite libraries (System)

This is a list of directories that are searched for test-suites whenever a suite reference is given as a relative path that cannot be resolved relative to the current suite. This includes direct suite references in the 'Procedure name' attribute of a 'Procedure call' or a 'Component' 'Id' reference as well as suites included through the 'Include files' attribute of the 'Test-suite' node.

The include directory belonging to the current version of QF-Test is automatically and invisibly placed at the end of the library path. This ensures that the common library qfs.qft can always be included without knowing its actual location and that its version is matching the version of QF-Test at all times.

Note If the command line argument -libpath <path> is given it will override the settings of this option. In interactive mode, the value of the command line argument is displayed here, but it will not be saved with the system configuration unless it is modified.

		Figure 29.8:  License options

Normally QF-Test license bundles contain a homogenous mix of GUI engines. For example, a bundle of QF-Test/swing licenses only supports the AWT/Swing engine, QF-Test/suite licenses support both AWT/Swing and SWT for all included licenses. For these kinds of simple licenses these license settings can be ignored.

A small problem arises in case of mixed engine licenses where some GUI engine is included only for a part of the licenses. An example for this is a license bundle that was formerly purchased for qftestJUI, upgraded to QF-Test/suite with QF-Test 2.0 and then extended with further QF-Test/swing licenses, say two licenses for QF-Test/suite and another two for QF-Test/swing. Such a license allows running four concurrent instances of QF-Test, but only two of these can make use of the SWT engine. If more than two instances are started with SWT support there will be a license conflict.

When QF-Test detects such a mixed license bundle for the first time it asks the user which engine licenses to use. The choice made then can be changed here at any time. Besides, QF-Test can be started with the command line argument -engine <engine> to override the supported GUI engines for this execution.

Last update: 01/27/2012 Copyright © 1999-2012 Quality First Software GmbH