Proxy model

HCL OneTest™ UI 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 HCL OneTest™ UI 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 HCL OneTest™ UI 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 HCL OneTest™ UI.

The HCL OneTest™ UI 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 HCL OneTest™ UI client side. TestObjects have a reference to the ProxyObject which in turn refers to the AUT control under test. Proxy model

For each testing environment that HCL OneTest™ UI supports, such as Java, HTML, .NET, Win32, 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 HCL OneTest™ UI installation directory. These customization files act as a directory for HCL OneTest™ UI to know which ProxyObject is used for any given AUT control.

Note: 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>