NOTICE: Our Community is moving. Get more information. Updated information on a New Login Process
Typically automation steps in a Visual test do not require extra synchronization steps to be inserted but there are scenarios when the Visual test needs to wait for the the application under test to complete an operation before continuing.
Previous versions of the Visual test only allowed for inserting a hard coded delay, or waiting for the existence (or disappearance) of an object in the application under test, however, there are scenarios where these are not sufficient.
Version 18.5 of Silk Test Workbench introduces a new step type that allows the Visual test to wait for the value of a property of a control.
Consider the example where the only indication that the Visual test should proceed is when a control is enabled, typically as a result of a long operation completing, for example, a button on a dialog is enabled when a long running process is complete.
A Wait for Property step that waits for the Enabled property of the button to be equal to True will achieve this. To insert the step select Insert -> Synchronization and Timing -> Wait for property.
Figure 1: Inserting a Wait for Property step.
The Wait for Property step created will be empty.
Figure 2: An empty Wait for property step
The step needs to know what control to use, click on the Locator entry in the Properties window and then select the Identify button. Use one of the options to identify the control (the easiest is to use Application Under Test), use the mouse to point at the control and click it to select it.
Figure 3: Identifying the control
This fills the dialog with the information about the control, this includes the Class Name, Locator, and Property names. Select the Property drop-down and select the Enabled property.
Figure 4: Properties window populated with the control details
Since we want to wait for the control to be enabled, we need to wait for the property value to be True, if we wanted to wait for the control to be disabled we would wait for the property value to be False. Note that the Value parameter can be specified as a literal, a variable, an expression, or refer to an ActiveData value.
The final thing that needs to be set is the Timeout (milliseconds) entry, this defaults to 5000ms (5 seconds), the step will wait for up to this amount of time for the property value to match. Change this to suite your requirements.
You should have something that looks like Figure 5 below.
Figure 5: Completed Wait For Property step
If the timeout expires, that is, the property value does not change to Value defined in the step within the timeout period, this is deemed to be a Playback Error and the test will terminate. If you execute the Visual test from the Workbench this will show the Playback Error dialog. If the Visual test is executed from the command line program (STW.EXE) the test will terminate and the error reported on the command line.
Figure 6: Playback error message when the timeout expires
If terminating the Visual test is not appropriate there is a way for the test to trap that the timeout expired and to perform some actions to recover from the timeout.
Use the menu item Insert -> Error Handling
This prevents the Visual test from terminating with a Playback Error.
Use menu item Insert -> Test Logic -> If
Then edit the condition to test if st_LastError is not an empty string.
Add recovery test steps between the If and End If steps.
For example, close the dialog, record something to the Result.
This resets the error handing mechanism to the default.
The steps in the Visual test will look something like this.
Figure 7: Wait for Property with error handling and recovery code
The addition of the Wait for Property step gives Visual test authors more options when automation applications which require more than the default automatic synchronization resulting in more robust and reliable Visual tests.