Implementing Test Record for a Custom Control Using a .NET DLL
Recording a business component or test on a control means listening to the activity of that control, translating that activity into test object method calls, and writing the method calls to the test. Listening to the activities on the control is done by listening to control events, by hooking Windows messages, or both.
Note: If you plan to create GUI tests using keyword-driven testing, and not by recording steps on an application, you do not need to implement Test Record.
Write the code for Test Record by implementing the methods in the code segment created by the wizard based on the IRecord interface (provided with the UFT One .NET Add-in Extensibility SDK). Your Test Record implementation does not inherit from the existing test object to which the custom control is mapped. It replaces the existing object's Test Record implementation entirely. Therefore, if you need any of the existing object's functionality, code it explicitly.
Before reading this section, make sure you are familiar with Create Custom Servers.
This section describes:
For more information on the interfaces, classes, enumerations, and methods in this section, see the API Reference.
Implementing the IRecord Interface
To implement the IRecord interface, override the callback methods described below and add the details of your implementation in your event handlers or message handler.
The examples provided below for each callback method are written in C#.
CustomServerBase. InitEventListener is called by UFT One when your Custom Server is loaded. Add your event and message handlers using this method.
Implement handlers for the control's events.
A typical handler captures the event and writes a method to the test. This is an example of a simple event handler:
public void OnMouseDown(object sender, MouseEventArgs e) { // If a button other than the left was clicked, do nothing. if(e.Button != System.Windows.Forms.MouseButtons.Left) return; /* For more complex events, here you would get any other information you need from the control. */ // Write the test object method to the test RecordFunction("MouseDown", RecordingMode.RECORD_SEND_LINE, e.X,e.Y); }
For more information, see Implementing Test Record for a Custom Control Using a .NET DLL.
Add your event handlers in InitEventListener:
public override void InitEventListener() { ..... // Adding OnMouseDown handler. Delegate e = new MouseEventHandler(this.OnMouseDown); AddHandler("MouseDown", e); ..... }
Note that if the Test Record implementation will run in the context of the application being tested, you can use the following syntax:
SourceControl.MouseDown += e;
If you use this syntax, you must release the handler in ReleaseEventListener.
Add a remote event listener.
If your Custom Server will run in the UFT One context, use a remote event listener to handle events. Implement a remote listener of type EventListenerBase that handles the events, and add a call to AddRemoteEventListener in method InitEventListener.
public class EventsListenerAssist : EventsListenerBase { // class implementation. } public override void InitEventListener() { ... AddRemoteEventListener(typeof(EventsListenerAssist)); ... }
When you implement a remote event listener, you must override EventListenerBase.InitEventListener and EventListenerBase.ReleaseEventListener in addition to overriding these callback functions in CustomServerBase. The use of these EventListenerBase callbacks is the same as for the CustomServerBase callbacks. For details, see the EventsListenerBase class.
When you handle events from the UFT One context, the event arguments must be serialized. For details, see CustomServerBase.AddHandler(String, Delegate, Type) and the IEventArgsHelper interface.
To avoid the complications of remote event listeners, run your event handlers in the Application under test context, as described above.
OnMessage is called on any window message hooked by UFT One. If Test Record will run in the UFT One context and message handling is required, implement the message handling in this method.
If Test Record will run in the Application under test context, do not override this function.
For details, see CustomServerBase.OnMessage.
If Test Record will run in the UFT One context and listen to windows messages, override this method to inform UFT One whether the Custom Server handles only messages intended for the specific custom object, or whether it handles messages from child objects, as well.
For details, see IRecord.GetWndMessageFilter.
See also:Troubleshooting and Limitations - Running the Support You Designed.
UFT One calls this method at the end of the recording session. In ReleaseEventListener, unsubscribe from all the events to which the Custom Server was listening. For example, if you subscribe to OnClick in InitEventListener with this syntax,
SourceControl.Click += new EventHandler(this.OnClick);
you must release it:
public override void ReleaseEventListener()
{
....
SourceControl.Click -= new EventHandler(this.OnClick);
....
}
However, if you subscribe to the event with the AddHandler method, UFT One unsubscribes automatically.
Writing Test Object Methods to the Test
When information about activities of the control is received, whether in the form of events, Windows messages, or a combination of both, this information must be processed as appropriate for the application and a step must be written as a test object method call.
To write a test step, use the RecordFunction method of the CustomServerBase class or the EventsListenerBase, as appropriate.
Sometimes, it is impossible to know how an activity should be processed until the next activity occurs. Therefore, there is a mechanism for storing a step and deciding in the subsequent call to RecordFunction whether to write it to the test. For details, see RecordingMode Enumeration.
To determine the argument values for the test object method call, it may be necessary to retrieve information from the control that is not available in the event arguments or Windows message. If the Custom Server Test Record implementation is running in the context of the application being tested, use the SourceControl property of the CustomServerBase class to obtain direct access to the public members of the control. If the control is not thread-safe, use the ControlGetProperty method to retrieve control state information.