Proxy model
Functional Tester interacts with application-under-test (AUT) controls through two elements: Proxy objects and Test objects.
Interaction through proxy objects
Proxy objects are similar to wrapper classes for the real controls under test. Any Functional Tester framework communication with AUT controls happen through these proxy objects. Proxy objects are created and placed where the control under test can be accessed and queried for information. A proxy is written as a Java or C# class, which implements the prescribed Functional Tester interface for a GUI test object in the AUT. When your application is enabled for testing, the proxy classes are loaded into the application and they become part of it. A proxy object wraps around the actual GUI test object (the native object) in your application, making it testable by Functional Tester.
The Functional Tester framework supports creating a new ProxyObject class or extending any available ProxyObject class to support testing new controls.
Interaction through TestObject
TestObjects are the script-side interface objects for the control under test. A control is exposed as a TestObjects to the test script. For example, a button control is exposed as GuiTestObject. Top level controls like dialogs and frames are exposed as TopLevelTestObject.
The execution of the TestObject methods in turn happens through the corresponding ProxyObject. TestObjects reside in the Functional Tester client side. TestObjects have a reference to the ProxyObject which in turn refers to the AUT control under test.
For each testing environment that Functional Tester supports, such as Java, HTML, .Net, Win32, Siebel, and SAP, domain objects are established. Under each domain there are ProxyObject classes for all supported AUT controls. The mapping information between ProxyObject classes and AUT controls are stored inside customization files in the Functional Tester install directory. These customization files act as a directory for Functional Tester to know which ProxyObject is used for any given AUT control.
The main customization mapping file is rational_ft.rftcust. There are other domain specific customization files with the .rftcust extension as well.
ProxyObjects can also be extended to create new ProxyObject classes to support unsupported UI controls. For example, to support the .Net 2.0 DataGridView control, you can create a new proxy class Rational.Test.Ft.Domain.Net.DataGridViewProxy and insert the corresponding mapping entry in the rational_ft.rftcust file. The following code is an example of the updated section in the customization file.
<Obj L=".Proxy"> <ClassName>[WhidbeyControls]Rational.Test.Ft.Domain.Net.DataGridViewProxy</ClassName> <Replaces/> <UsedBy>[System.Windows.Forms]System.Windows.Forms.DataGridView</UsedBy> </Obj>
Related concepts