- Test Script Synchronization
- Placing a Generic Delay in Your Script
- Waiting for Test Objects to Come into Existence
- Timing How Long Something Takes to Execute in a Script
- Working with Test Objects
- Working with the Clipboard Object
- Viewing an Objects Properties
- Retrieving All Properties of a Test Object
- Retrieving the Value of a Single Property
- Programmatically Retrieving Data from an Object in My Application
- Determining a Test Objects Valid Test Data Type Arguments to getTestData()
- Using getTestData to Extract Data from a Text Field
- Using getTestData to Extract Data from a List
- Using getTestData() to Read Data in a Table
- Using getTestData() to Extract Data from a Tree
- Obtaining Data from a Test Object That the Rational Functional Tester Verification Point Wizard Does Not Capture
- Creating a Custom Verification Point
- Changing the Value of a Test Objects Property
- Evolving Custom Scripting into Reusable Methods
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Placing a Generic Delay in Your Script
Enhancing Rational Functional Tester’s default synchronization can be as simple as adding a generic delay to your script. You can use the sleep() method (Sleep() function in the .NET version). This is available to you while recording or via coding.
When you are recording and notice that your application is slow to respond, you can turn to the Script Support Functions button on your toolbar. This is shown in Figure 3.1.
)
Engaging this button provides you with the option to place a sleep() method into your script. Please refer to Figure 3.2 for a visual reference.
)
To use this function, you specify the number of seconds that you think your script will need to handle any latency issues with your application. You then click the Insert button. If you were using the Eclipse version of Rational Functional Tester, you would see a line in your script that looks like the following:
sleep(2.0);
Otherwise, using the .NET Studio version of Rational Functional Tester, you would see:
Sleep(2.0)
Listing 3.1 shows what these lines look like in the context of a test script:
Listing 3.1. Using sleep() / Sleep() in a script
Java
public void testMain(Object[] args)
{
startApp("ClassicsJavaA");
// PAUSE EXECUTION, USING sleep() METHOD, FOR 2 SECONDS
sleep(2.0);
// Frame: ClassicsCD
tree2().performTest(VerifyComposerListVP());
classicsJava(ANY,MAY_EXIT).close();
}
VB.NET
Public Function TestMain(ByVal args() As Object) As Object
StartApp("ClassicsJavaA")
' PAUSE EXECUTION, USING sleep() METHOD, FOR 2 SECONDS
Sleep(2.0)
' Frame: ClassicsCD
Tree2().PerformTest(VerifyComposerListVP())
ClassicsJava(ANY,MAY_EXIT).Close()
Return Nothing
End Function
If you execute either of the scripts displayed in Listing 3.1, execution pauses when it hits the sleep() method. The duration of the pause is determined by the number of seconds that was specified in the argument to the method (the number in the parentheses). In the case of the examples in Listing 3.1, execution pauses for two seconds.
You also have the ability to code these lines directly into your scripts. For instance, you might not have recorded these delays because you didn’t experience poor performance with your application while recording. However, upon playback of your scripts, you see periodic latency issues that surpass the default synchronization built into Rational Functional Tester. Using, the playback logs, you can find out what object was unable to be found on playback. This enables you to go into your script and code in the necessary sleep() lines. Please remember that you need to provide, as an argument to the method, the number of seconds to pause. This should be a floating number (for example, 2.0, 3.5, and so on).
The benefit of using the sleep() method is that you can now place extended synchronization capabilities right within your scripts, freeing you from the dependency of global playback settings. The downside of using the sleep() method is you are dealing with a static period of time. In other words, your script has to pause for the specified period of time regardless of whether or not the application responds faster than anticipated.