Properties for classic Modules
Technical steering information for the object to be tested is contained in the ObjectMap of a Module in Tosca. Steering information of the controls can be found in the ObjectControl.
ObjectMaps and ObjectControls are only used along with classic Modules and ModuleAttributes.
ObjectMaps and ObjectControls are automatically created when a test object is scanned. You can edit steering information and if you create Modules manually you are able to import ObjectMaps (see chapter "Importing ObjectMaps (classic Module)").
For further details on ObjectMap and ObjectControl options, please refer to chapter "Options for ObjectMaps and ObjectControls".
ObjectMap
Technical information of the ObjectMap depend on the technology (engine) used. Please see also the corresponding Engine Manuals for further information on engine-specific properties.
The following properties are available in Tosca. For further information on properties and parameters, please refer to chapter "Default properties for Modules".
Parameter name |
Description |
Valid values or examples |
---|---|---|
AvoidSnapper |
This specifies whether Modules and ModuleAttributes are excluded from being recorded by the Doku Snapper (see chapter "Document the execution of your tests"). |
|
This property is optional. This value specifies whether dynamic values or the entered string are used in the ObjectMap. If a value is set, the setting for this Module will become invalid in the Settings dialog (see chapter "Settings - ObjectMaps"). |
|
|
This property must be created manually. You can specify for each Module whether an execution result (test state) is displayed in Tosca Commander™ and scanned in the TestResult.xml file. This also applies to all ModuleAttributes that are contained in the Module. This property overwrites the global setting for Report Successful Execution of. |
|
|
Frame |
Modern web applications are usually divided into frames. The frame is identified with this parameter. |
|
If a Module has an embedded keyword, the value of this property is set to True. For further information on to embed keywords into Tosca Commander™ please refer to chapter "Embedding keywords". |
|
|
Keyword |
This is the reference to an individual control routine (keyword) which must be used upon test execution (see chapter "BASE I Keywords"). |
|
ScreenType |
Indicates the technology of the shown screen. |
JAVA, HTML, SAP, etc. |
TechnicalId |
Technical description of the screen. This allows the control level to clearly identify the window. |
e.g. the window caption |
If the UseWaitOn function is activated, the execution of the TestCase pauses until the condition that has been specified by the property WaitOnSpec is met. |
|
|
WaitOnSpec |
WaitOn expressions, which are applied to all derived TestSteps, are specified on the ObjectMap level by using the function WaitOnSpec. The property UseWaitOn must therefore be activated. The property of an ObjectControl within the ObjectMap must be referenced. This property can also be specified on the attribute level for individual controls (see "WaitOnSpec and UseWaitOn"). The syntax for the boolean values true and false is defined in the Settings dialog at Engine->Bool Comparison. |
<attribute name>.<property>=true Please note the engine specific syntax (case-sensitive). |
Parameter ForceLogEntry
ObjectControl
ObjectControls contain technical information required for steering controls. The ModuleAttributes contain business-based descriptions.
In Tosca we distinguish between the following ObjectControl types:
-
ControlSimple
This is a simple control, such as an EditBox.
-
ControlGroup
Combines complex controls into a group consisting of ControlGroupItems (e.g. RadioButtons – see chapter "Grouping controls (ControlGroup)")
-
CustomControl
Freely definable controls which may contain additional, subordinated objects ObjectCustomControlAttribute.
The following properties are available in Tosca. For further information on properties and parameters, please refer to chapter "Default properties for Modules" and the corresponding Engine Manuals.
Parameter name |
Description |
Valid values or examples |
---|---|---|
AvoidSnapper |
This specifies whether Modules and ModuleAttributes are excluded from being recorded by the Doku Snapper (see chapter "Document the execution of your tests"). |
|
This property specifies which HTML events are triggered when an Input action is performed. One or more events can be specified, separated by semicolons ; (see setting "EventsToBeFiredAfterInput" and chapter "Parameter - FireEvents"). |
Default value: onchange;onblur |
|
ForceLogEntry |
This property must be created manually. You can specify for each ModuleAttribute whether an execution result (test state) is displayed in Tosca Commander™ and scanned in the TestResult.xml file. This property overwrites the global setting for Report Successful Execution of. |
|
Steering |
This parameter can be used to define additional steering information for a control. The technology used determines the values to be applied. Please see also the corresponding Engine Manuals. |
Steering=HEADER |
TechnicalId |
Technical description of the control. This allows the control to be uniquely identified. |
e.g. ID=txtInput, Name=cmdOK, etc. |
Control type |
e.g. EditBox, HTMLLink |
|
UseWaitOn |
If the UseWaitOn function is activated, the execution of the TestCase pauses until the condition that has been specified by the property WaitOnSpec is met (see "WaitOnSpec and UseWaitOn"). |
|
ValueRange |
The ValueRange may contain a list of values that are separated by semicolons. When the ModuleAttribute is used in a TestCase, these values are provided in a drop-down list in the Value column. The exact string value including spaces is applied. |
Example: see chapter "Steering Test Objects" |
WaitAfter |
You can specify time intervals (in milliseconds) for each control that will be waited after steering the control. This is mainly used for dynamic screen masks that change according to the input of certain values. |
|
WaitBefore |
Specify a time interval in milliseconds for each control that will be waited prior to control steering. This is mainly used for dynamic screen masks that change according to the input of certain values. |
|
WaitOnSpec |
WaitOn expressions, which are applied to all derived TestSteps, are specified on the ObjectControl level by using the function WaitOnSpec. The property UseWaitOn must therefore be activated (see "WaitOnSpec and UseWaitOn"). |
.<property>=true |
WaitOn expressions, which are applied to derived TestSteps, are specified on the ObjectControl level by using the function WaitOnSpec. The property UseWaitOn must therefore be activated (True).
The property of an ObjectControl is referenced. If a referenced ObjectControl contains WaitOn expressions, these expressions are ignored.
Syntax: |
.<property>=true |
The syntax of the boolean values true and false is defined in the Settings dialog at Engine->Bool Comparison.
In the example below, the application waits until the Restart button is active before clicking on the button.
WaitOnSpec on the ObjectControl level |
ControlGroup items require the attribute name of the sub-item to be specified.
Syntax: |
<attribute name of item>.<property>=true |
In the example below, the test execution pauses until the RadioButton Old is enabled.
WaitOnSpec referencing to a ControlGroup item |