- 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
Programmatically Retrieving Data from an Object in My Application
Retrieving data from objects in your application is a critical and fundamental task. You might need to get the data so that you can use it at a later point in your test; you might get it because you’re creating your own verification point. No matter what your motivation is for pulling data from an object, the RFT API makes extracting data easy.
For the purposes of this chapter, the world of test objects is divided into two broad categories: those in which the RFT Verification Point Wizard sees data and those in which the RFT Verification Point Wizard doesn’t see data. The TestObject techniques discussed in this chapter (with the exception of the “Working with the Clipboard Object” section) are limited to the former category of test objects, which is covered in other chapters.
You use one of two methods to get data from a test object: getProperty() or getTestData(). getProperty() is appropriate if the data is available as a property of the test object and the format of the data as a property value suites your needs. For example, if you want to get the visual text on a button (such as the Place Order button in Classics or the Search button at www.google.com), getProperty() would work fine. If you examine these objects using the Test Object Inspector (see the “Viewing an Object’s Properties” section), you can see that in Classics, you need to get the value of the label property; the Google button would require that you get the value property.
Things become more interesting when the data you’re interested in is available as a property, but not in the desired format. For example, on the Rational Support home page, there is a list of products (see Figure 3.19).
)
Imagine you wanted to get the list values. Examining the list under the Test Object Inspector microscope reveals a .text property whose value is the contents of the list. There’s a problem, though: It’s one big string—you don’t know where the breaks between items are. Sometimes it is not a critical issue. For instance, you might just want to know if “Functional Tester” appears anywhere in the list. If that is the case, you can simply use getProperty() to capture the .text property and be done with it. However, what if you want to know how many items are in the list? To achieve this, getProperty() does not suit your needs. In this instance, the usage of getTestData() would aid your efforts.
If you run Rational Functional Tester’s Verification Point and Action Wizard and click Data Verification Point, you see that Rational Functional Tester is able to identify each list item discretely. Because Rational Functional Tester’s Data Verification Point Wizard is able to capture the data, you can capture the data in code. In fact, any data that the Rational Functional Tester Data Verification Point Wizard is able to capture can be retrieved programmatically in a script.
Your script can retrieve any data from a test object that is accessible to the Data Verification Point Wizard by invoking the getTestData() method on the test object. Here is the method signature:
ITestData getTestData( String testDataType )
getTestData() does precisely what its name suggests: It gets and returns data from a test object. That’s it. It does not verify anything. It requires a String argument—the test data type—to capture from the test object. The notion of a test data type requires some explanation.
Test Data Types
Recall that when you use Rational Functional Tester’s Verification Point Wizard, you have to indicate to the wizard which test data to verify. For example, if you’ve selected a list object (as in the case of the Rational Support site example), you have to express if you want Rational Functional Tester to verify all the values in the list or just the selected elements. You can see this in Figure 3.20.
)
The argument passed to getTestData() indicates to getTestData() that same detail that you express to the Verification Point Wizard when you select a value in the Data Value list. In the case of a recorded verification point, it tells Rational Functional Tester which data to retrieve and verify; in the case of getTestData(), it indicates which data to retrieve and return to the caller of getTestData().
ITestData
getTestData() returns the data as a Java interface type: ITestData. The ITestData interface is inherited by several subinterfaces, each of which has methods to store and manipulate specific types of data, for example, ItestDataList (for data in lists), ITestDataTable (for data in tables), and ITestDataTree (for data in trees). Each of these interfaces has methods to query and extract data in the manner appropriate for that data structure. For example, if you retrieved the data in a table, you might want to know how many columns and rows of data there are. You might also want to get all the values in row 3 or column 2. ITestDataTable has methods that make this possible in an intuitive fashion. When working with lists, you might want to know how many items are in the list and get all the values. ITestDataList has methods to do this.
Even though the signature of the return type of getTestData() is ITestData (the base interface type), what will actually be returned is a reference to a subinterface of ITestData, for example, ITestDataTable. Even though you can always treat any of the returned data as base ITestData (that is you can upcast the returned reference), you almost always assign to a variable of the specific subinterface type so that you can call the specific methods available in the subtype. In the case of Java, you explicitly downcast; in VB.NET, you can use an implicit downcast. For example (don’t worry here about the argument to getTestData(); the focus here is on the downcasting), Java:
ITestDataTable iData = (ITestDataTable)someTable().getTestData( "contents" );
In VB. Net:
Dim iData As ITestDataTable = someTable.GetTestData( "contents" )
Using getTestData() successfully requires that you:
- Know the appropriate test data type argument for the test object in question.
- Know which methods to use in the returned ITestData to access the data elements.
In the next sections, we look at how to acquire this knowledge.