Learning to Create QuickTest Support for a Custom WPF Control
In this tutorial you manually create support for a WPF Calendar control, learning the basics of creating a WPF Add-in Extensibility toolkit support set. A toolkit, or an environment, is a set of controls for which you want to provide support in one package. In this tutorial, the toolkit is named MyWpfToolkit, and contains only the Microsoft.Windows.Controls.Calendar control.
To perform this tutorial you must have Microsoft Visual Studio 2008 installed, in addition to the WPF and Silverlight Add-in Extensibility SDK (which must be installed after Visual Studio). This tutorial uses the QuickTest WPF CustomServer project template in Visual Studio to set up the files necessary to create the toolkit support set. When you develop your own support, if you want to create your toolkit support set files manually, follow the steps in How to Create Support for a Custom WPF or Silverlight Toolkit.
Note: You develop support for a Silverlight control in much the same way as you develop a support for a WPF control. Throughout the tutorial, where modifications would be necessary if this were a Silverlight toolkit support set, the modifications are explained.
The links in this tutorial link to the Mercury.QTP.WPF.CustomServer namespace section in the Custom Server API Reference. For the most part, the information there is relevant for Silverlight as well, and is identical to the information provided in the Mercury.QTP.Slv.CustomServer namespace section. An alternative link for the Silverlight information is provided when the information is significantly different.
The WPF Calendar application is installed in: <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application.
The <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Support folder contains the Microsoft Visual Studio solution and XML files that make up support for this control, similar to the support you create in this tutorial. You can refer to these files while you perform the tutorial.
This tutorial includes:
- Planning Support for the WPF Calendar Control
- Setting Up the WPF Add-in Extensibility Project for the WPF Calendar Control
- Designing the Toolkit Configuration File
- Designing the Test Object Configuration File
- Deploying and Testing the Preliminary Toolkit Support Set
- Design the Basic Custom Server
- Implement Support for Retrieving Identification Property Values
- Deploy and Test Your Basic Custom Server and Identification Property Support
- Implement Support for Running Test Object Operations
- Deploy and Test Your Support for Test Object Operations
- Implement Support for Recording
- Deploy and Test Your Support for Recording
Planning Support for the WPF Calendar Control
In this section, you study the behavior of the control that you want to support and the way QuickTest recognizes it and interacts with it. You then determine what you need to customize in QuickTest's behavior in order to enable creating test steps that are more meaningful and easier to maintain.
- Use the Object Spy in QuickTest to see how QuickTest recognizes the controls in the Calendar application
![]()
- Open QuickTest.
- Select Automation > Record and Run Settings, and make sure that the selections in the Windows Applications tab enable QuickTest to record and run tests on the calendar application.
- Run the Object Spy and spy on the WPF Calendar.
QuickTest recognizes the Calendar application as a WpfWindow. Within this window, it recognizes the Microsoft.Windows.Controls.Calendar control as a generic WpfObject and the System.Windows.Controls.TextBox as a WpfEdit object.Additionally, within the in the Microsoft.Windows.Controls.Calendar control, QuickTest recognizes the days as independent WpfButtons in the WpfWindow.QuickTest ignores other user interface elements contained in the Calendar control, such as the right and left arrows, and the month and year banner.
- Learn the Calendar control using QuickTest, adding it to an object repository
- Open the Object Repository
- Click the Add Objects to Local button
- Click on an area in the calendar.
QuickTest learns the application as a WpfWindow. Within this window, it separately learns the calendar display area as a generic WpfObject and the Selected Date box as a WpfEdit object.The days are learned as independent WpfButtons, but other user interface elements, such as the right and left arrows, and the month and year banner, are not learned at all.
- Record a test on the Calendar control
- Click Record.
- Click on different areas in the calendar.
When you click on the right or left arrows, or on the month and year banner, QuickTest records a generic click on the WpfObject, specifying the coordinates of the location you clicked.When you click a day and select it, or when you click in the Selected Date box, nothing is recorded.When you click in other areas of the application, QuickTest records a generic click on the WpfWindow.
- Conclusion: Develop a MyWpfCalendar Test Object Class
- For functional testing purposes, the Microsoft.Windows.Controls.Calendar control should be represented in QuickTest by one MyWpfCalendar test object.
- The buttons within the Calendar control should not be treated as separate controls.
- The Selected Date box is a read-only box, on which no user activity is possible and no steps are recorded. Therefore, the System.Windows.Controls.TextBox control does not have to be supported as part of the MyWpfCalendar test object, and does not need any customization for functional testing.
- The MyWpfCalendar test object class should be based on the existing QuickTest test object class, WpfObject, and extend its capabilities.
- The MyWpfCalendar test object class should support calendar-related operations.
In this tutorial you will develop support for the following test object methods: SetDate (default operation), Next, Previous, and a SelectedDate test object property.
- User operations performed on the calendar's different user interface elements, should be interpreted and recorded as high-level operations on the calendar as a whole. For example: SetDate, Next, Previous, and so on.
- The MyWpfCalendar test object class should support identification properties relevant for a calendar, such as is_today_highlighted.
Setting Up the WPF Add-in Extensibility Project for the WPF Calendar Control
A WPF Add-in Extensibility support set consists of the
following mandatory files:
- A Test Object Configuration XML File. In this file, new test object types are defined. For details, see The Test Object Configuration XML File.
- A toolkit configuration file. In this file WPF control types are mapped to test object types and to the custom servers implementing their record and run logic. For details of the schema, see Toolkit Configuration Schema.
- .Net DLLs containing the implementation of custom servers. For details, see Custom Servers.
The WPF and Silverlight Add-in Extensibility SDK
installs a project template and a setup dialog box in Microsoft Visual Studio
that assist you in setting up the files that you need to create the toolkit
support set.
Use the template for each control you want to support. The
template sets up both the XML files and the Microsoft Visual Studio solution
that you need to create the custom server DLL. When you create support for more
than one control in a toolkit, you have to combine the XML content created for
each control into one toolkit configuration file and one test object
configuration file for the toolkit.
In this tutorial, because you are creating a toolkit support
for only one control, you can use the XML files created by the project template,
as is.
Create a WPF Add-in Extensibility Project in Microsoft
Visual Studio
- Select the Visual C# Windows project type and the QuickTest WPF CustomServer template, and click OK.
- Enter CalendarSrv as the project Name, and click OK. The WPF/Silverlight Custom Server Setup dialog box opens.
- In this dialog box, you provide specifications that describe the support that you want to create, and the files required to create this support are created accordingly.
- You create support for the MyWpfToolkit toolkit.
- Within this toolkit you create support for Microsoft.Windows.Controls.Calendar WPF controls.
- You create a MyWpfCalendar test object class, based on the standard QuickTest WpfObject class, to represent the Calendar controls in QuickTest.
- You create a CalendarSrv custom server class, to provide support for the controls. Within the CalendarSrv custom server class, you customize running operations, retrieving properties, recording, and child object handling.
- Click OK.
Note: If you were developing support for a Silverlight
control, you would select the Visual C#
Silverlight project type and the QuickTest Silverlight
CustomServer template.
In this tutorial:
Specify these details in the WPF Custom Server Setup
dialog box, as shown in the image below, selecting also the options for
automatically generating XML files, comments, and sample code.
Make sure to enter the Run
interface name and the Property interface
name shown below, as this tutorial does not use the default names provided
in the dialog box.
If you want to see more information on this dialog box,
see WPF/Silverlight Custom Server Setup
Dialog Box (in Microsoft Visual Studio).
The CalendarSrv solution is created with the relevant
files and references. The solution includes a toolkit configuration file (MyWpfToolkit.cfg), a test object configuration
file (MyWpfToolkitTestObjects.xml), and the C#
file for the custom server class (CalendarSrv.cs).
It also includes the reference to the Mercury.QTP.WpfAgent.dll file, that contains the
WPF Add-in Extensibility API.
Note: If you use the QuickTest Silverlight CustomServer template, the solution
created includes a reference to the Mercury.QTP.Slv.CustomServer.dll file, that
contains the Silverlight Add-in Extensibility API.
Designing the Toolkit Configuration File
The name of the toolkit configuration file informs QuickTest
of the new supported environment. After you deploy this file to the correct
location on a QuickTest computer, when QuickTest opens, it displays the
environment in the Add-in Manager, as a child node beneath the WPF Add-in. If
you select the check box for this environment, QuickTest loads the support that
you provide for it. (If you are working with Silverlight, you must also select
the Silverlight Add-in.)
The configuration file content defines how the controls are
supported, which test object classes and custom servers are used for each custom
control and so on.
Open the MyWpfToolkit.cfg
file to see its content.
The MyWpfToolkit.cfg file was
created automatically based on the specifications you provided. Therefore, it
already has all of the necessary content to support the WPF Calendar control is
the MyWpfToolkit environment.
The Control element's
attributes specify that the controls of Type Microsoft.Windows.Controls.Calendar (the full
control type name including namespaces must be specified) is MappedTo the test object class MyWpfCalendar.
The CustomServer >
Component element specifies the custom server DLL and type that provides
support for this control type.
Note: The custom server type
must be a full type name including namespaces, and in Silverlight it must
include additional information, as described in the Toolkit Configuration Schema
Help.
Designing the Test Object Configuration File
You use the test object configuration file to introduce the
MyWpfToolkit environment and its test object class to QuickTest.
- Open the MyWpfToolkitTestObjects.xml file.
- To extend the test object class and add definitions for the
calendar-specific operations and identification properties, replace the comment
lines within MyWpfToolkitTestObjects.xml so
that your test object configuration file contains the following:
- The Previous, Next, and SetDate test object methods and the SelectedDate property, including all relevant parameters, return values, and their types. SetDate is the default operation for this test object class.
- The devname, devnamepath, regexpwndtitle, x, y, and is_today_highlighted identification properties.
- The first 5 properties are supported by the base class, and the implementation for retrieving their values is inherited. However, identification property definitions are not automatically inherited, which is why you must define them here.
- For each identification property, you specified whether it should be included in the test object description, used as an assistive property, or available for verification in checkpoints.
The MyWpfToolkitTestObjects.xml file was created with
the AddinName attribute in the TypeInformation element set to WPF and the PackageName
attribute set to MyWpfToolkit. This associates the
test object configuration file (and the test objects defined in it) with the
MyWpfToolkit environment under the WPF Add-in. If, when QuickTest opens, you do
not select the MyWpfToolkit environment, QuickTest ignores the test object class
definitions in this file.
Note: When developing support for a Silverlight control, the
TypeInformation element is set to Silverlight.
Based on the information you provided in the WPF Custom Server
Setup dialog box, the ClassInfo element for the
MyWpfCalendar test object class was also created,
specifying WpfObject as its base class. This means
that the new MyWpfCalendar test object class you
define inherits the WpfObject methods, generic type,
Help file, etc.
You have now defined:
Deploying and Testing the Preliminary Toolkit Support Set
After defining the MyWpfCalendar test object class in the test object
configuration file and mapping the Calendar control to this test object class in
the toolkit configuration file, you can already test the effect of using the
toolkit support set with QuickTest.
Note: When you develop your own toolkit support set, if you
modify attributes of Identification Property
elements in the test object configuration file, keep the DevelopmentMode attribute of the TypeInformation
element set to true during the design stages of the
custom toolkit support. Before you deploy the custom toolkit support set for
regular use, be sure to remove this attribute (or set it to false). This is not required when performing this tutorial
lesson. For more information, see Modifying
Identification Property Attributes in a Test Object Configuration File.
To deploy the toolkit
support set:
- Copy the MyWpfToolkitTestObjects.cfg file to <QuickTest installation folder>\dat\Extensibility\WPF.
- In the <QuickTest installation folder>\dat\Extensibility\WPF folder, create a folder named MyWpfToolkit.
- Copy the MyWpfToolkit.cfg file to the <QuickTest installation folder>\dat\Extensibility\WPF\MyWpfToolkit folder.
Note: If you were developing support for a Silverlight control,
you would replace WPF in the paths above with Slv.
To test the toolkit
support set:
- After you deploy the toolkit support set, open QuickTest.
- Select the check box for MyWpfToolkit and click OK. QuickTest opens and loads the support you designed.
- Use the Define New Test Object button in the Object Repository dialog box to open the Define New Test Object dialog box. The MyWpfToolkit environment is displayed in the Environment list. When you select the MyWpfToolkit environment from the list, the MyWpfCalendar test object class that you defined in the test object configuration file is displayed in the Class list.
- Select Tools > Object Identification. In the Object Identification dialog box, when you select the MyWpfToolkit environment in the Environment list, the identification property definitions for the MyWpfCalendar test object class should match the definitions in the test object configuration file.
- Run the sample control by opening the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file.
- In QuickTest, perform the following activities on the Calendar control, to see how QuickTest recognizes the control. (For more information on working in QuickTest, see the HP QuickTest Professional User Guide.)
- Use the Object Spy to see how QuickTest recognizes the Calendar control and to view its identification properties and test object operations:
- The calendar is represented by a MyWpfCalendar test object class.
- The calendar day numbers are still recognized as separate test objects. Later in this tutorial you will customize child object handling to prevent that.
- The list of test object operations includes all of the operations (methods and properties) inherited from the WpfObject base class, as well as all of the operations that you defined in the MyWpfToolkitTestObjects.xml test object configuration file.
- The list of identification properties includes all of the properties that
you defined in the MyWpfToolkitTestObjects.xml
test object configuration file.
- The is_today_highlighted identification property has no value, because you have not yet implemented its retrieval. For all other identification properties, the value is provided as it would be for a WpfObject (because it is the base class).
- In the Expert View, type MyWpfCalendar("MyCalendar").
Note: QuickTest reads toolkit support files when it opens.
Therefore, if QuickTest is open, you must close QuickTest and open it again.
The Add-in Manager dialog box displays MyWpfToolkit as a child of the WPF environment in
the list of available add-ins. (If the Add-in Manager dialog box does not open,
see the HP QuickTest Professional Add-ins Guide for
instructions.)
Note: QuickTest establishes its connection with an
application when the application opens. Therefore, if the Calendar application
is open, you must close it and run it again.
Design the Basic Custom Server
For each custom control that you want to support, you develop
a custom server class, that derives from the CustomServerBase
class. The resulting custom server DLL runs in the context of the application
and interfaces between QuickTest and the custom control.
In this section, you design the CalendarSrv custom server
class to support the Calendar control.
- Open CalendarSrv.cs. The basic framework of the class was created based on the specifications that you provided in the WPF Custom Server Setup dialog box.
- The class inherits from CustomServerBase.
- In the Using section, the class includes a reference to the Mercury.QTP.WPF.CustomServer namespace in the WPF Add-in Extensibility API.
- The class definition includes the list of interfaces it will implement: IRecord, ICalendarRun, IComponentDetector, ICalendarProperties.
- In your project, add a reference to <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WPFToolkit.dll.
- In Calendar.cs, add a using Microsoft.Windows.Controls; statement. This enables IntelliSense for the Microsoft.Windows.Controls.Calendar control type in Visual Studio.
- In the CalendarSrv class, implement a common helper property that returns a
reference to the custom Calendar object. You can use this throughout your custom
server code to access the custom control's events, methods, and
properties:
private Calendar MyCalendar
{
get
{
return UtilityObject.ApplicationObject as Calendar;
}
} - You specified, in the WPF Custom Server Setup dialog box, that you want to customize child object handling. Therefore, a preliminary implementation of the IsKnownPartOf method in the IComponentDetector interface was created in the CalendarSrv class.
- Locate the ICalendarProperties interface
definition in the CalendarSrv.cs file.
[CustomPropInterface()]
public interface ICalendarProperties
{
object MyCustomProperty
{
get;
}
} - Replace the example object MyCustomProperty with bool is_today_highlighted to complete the interface definition.
- Locate the interface implementation in the CalendarSrv class:
public object MyCustomProperty
{
get
{
return null;
}
}
Note: If you use the QuickTest Silverlight
CustomServer template, the class includes a reference to the Mercury.QTP.Slv.CustomServer namespace in the
Silverlight Add-in Extensibility API.
This enables you to access the methods, properties, and events
of Microsoft.Windows.Controls.Calendar, by
double-clicking the reference node in the Visual Studio Solution Explorer. You
need to be familiar with these so that you can design code that interacts with
the Calendar control.
Modify the IsKnownPartOf
method to always return true. This means that QuickTest will treat all child
objects within the Calendar as part of the calendar and not as independent
objects.
Implement Support for Retrieving Identification Property Values
In this section, you implement the property value retrieval
interface in the CalendarSrv class to support retrieving the values of
identification properties from the Calendar control.
You specified, in the WPF Custom Server Setup dialog box, that
you want to customize property retrieval. Therefore, the ICalendarProperties interface that you specified
was defined in the CalendarSrv.cs file, tagged
with the CustomPropInterface attribute, and
implemented in the CalendarSrv class for an
example property, MyCustomProperty.
Deploy and Test Your Basic Custom Server and Identification Property Support
In this section, you deploy the custom server that you
developed to support the Calendar control and test its effect on QuickTest.
- Build your solution and then deploy the custom server by copying the CalendarSrv.dll file to the <QuickTest installation folder>\dat\Extensibility\WPF\MyWpfToolkit folder. You do not need to deploy the XML files because you did not change them.
- Run the sample control by opening the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file.
- Use the Object Spy to see how QuickTest recognizes the Calendar control and its children, and to view its identification properties:
- The calendar is represented by a MyWpfCalendar test object class.
- The day numbers within the calendar are considered part of the Calendar control and are not represented by separate WpfButton test objects.
- The value of the is_today_highlighted property is displayed.
- The Selected Date box remains external to the Calendar control, and is still represented by a separate WpfEdit test object, as planned.
- Use the Add Objects to Local button in the Object Repository dialog box to learn the Calendar control. A MyWpfCalendar test object named calender1 is added to the object repository.
- Start a recording session and create a checkpoint that checks the value of the is_today_highlighted property of the calendar1 test object. Stop the recording session and run the step to verify that the property value is properly retrieved.
- In the Keyword View, create a test step with the calendar1 test object. The default SetDate operation is selected automatically. Enter a date in the Argument column (in the format: mm/dd/yyyy).
- Run the test. Because you have not yet implemented support for running test object methods, a run-time error occurs. In the next section, you implement this support.
Note: You can use an open instance of QuickTest because you
did not modify configuration files. However, if the Calendar application is
open, you must close it and run it again.
Implement Support for Running Test Object Operations
In this section, you implement the Run interface in the
CalendarSrv class to support running test object operations on the Calendar
control.
You specified, in the WPF Custom Server Setup dialog box, that
you want to customize running operations. Therefore, the ICalendarRun interface that you specified was
defined in the CalendarSrv.cs file, tagged with
the RunInterface attribute and implemented in
the CalendarSrv class for an example operation,
MyRunMethod.
- Locate the ICalendarRun interface
definition in the CalendarSrv.cs file:
[RunInterface()]
public interface ICalendarRun
{
void MyRunMethod();
} - Replace the example void MyRunMethod(); with the
following lines to complete the interface definition to include all of the
operations you want to support:
void SetDate(string date);
void Prev();
void Next();
string SelectedDate
{
get;
} - Replace the MyRunMethod() example with the following implementation of the Calendar-specific methods and property:
- Add a using System.Windows.Media; statement to the CalendarSrv.cs file and then add the following helper functions:
|
public void SetDate(String date)
{
MyCalendar.SelectedDate = DateTime.Parse(date);
MyCalendar.DisplayDate = DateTime.Parse(date);
}
|
|
public string SelectedDate
{
get
{
return
MyCalendar.SelectedDate.Value.ToShortDateString();
}
}
|
|
public void Prev()
{
Button prev =
GetDescendantByName(UtilityObject.ApplicationObject, "PART_PreviousButton") as
Button;
RaiseButtonClickEvent(prev);
}
|
|
public void Next()
{
Button next =
GetDescendantByName(UtilityObject.ApplicationObject, "PART_NextButton") as
Button;
RaiseButtonClickEvent(next);
}
|
Note: If you were developing support for a Silverlight
control, you would tag each one of these methods with the Microsoft Silverlight
ScriptableMember attribute.
Deploy and Test Your Support for Test Object Operations
In this section, you deploy the custom server again and test
the support that you designed for running test object operations.
- Build your solution and then deploy the custom server by copying the CalendarSrv.dll file to the <QuickTest installation folder>\dat\Extensibility\WPF\MyWpfToolkit folder.
- Run the sample control by opening the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file.
- Use the Add Objects to Local button in the Object Repository dialog box to learn the Calendar control. A MyWpfCalendar test object named calender1 is added to the object repository.
- Create test steps with the calendar1 test object, using each of the test object operations: SetDate (mm/dd/yyyy), SelectedDate, Next, and Prev. (To view the value returned by the SelectedDate property you can use a msgBox statement.)
- Run the test and make sure that the operations are carried out correctly.
Implement Support for Recording
In this section, you implement the IRecord
interface and write the event and message handling methods to support recording
steps on the custom control.
There are three types of steps that need to be recorded for
the WPF custom calendar: Next, Prev, and SetDate.
- Next and Prev are recorded in response to Windows messages, when a user clicks the right and left arrows on the Calendar control. This is handled by the OnMessage method.
- SetDate is recorded in response to a control event—SelectedDatesChanged. This is handled by an event handler that you design and register to handle the relevant control event.
To implement support for recording in your custom
server class:
- In the CalendarSrv class, locate the section for the IRecord interface
implementation.
public void OnMessage(DependencyObject src, int msg, int wParam, int lParam)
{
}
public void RecordInit()
{
}
public void RecordStop()
{
} - Declare your event handler and implement RecordInit to register it to the control.
- You do not need to implement RecordStop because you registered the event handler using QuickTest's AddHandler method. This enables QuickTest to automatically remove the event handler at the end of a recording session.
- Add the OnSelectedDatesChanged event
handler implementation:
- Implement the OnMessage method as follows,
to support recording Prev and Next operations:
- This step is only necessary when developing support for Silverlight controls.
- Build your solution and then deploy the custom server by copying the CalendarSrv.dll file to the <QuickTest installation folder>\dat\Extensibility\WPF\MyWpfToolkit folder.
- Run the sample control by opening the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file.
- To test that the support you developed for recording is working correctly, start a recording session, select a day in the calendar, click the right arrow at the top of the calendar, and click the left arrow at the top of the calendar. SetDate, Next, and Prev steps should be recorded.
Note: When developing support for a Silverlight control, the
AddHandler
syntax is different. For details, see the Mercury.QTP.Slv.CustomServer namespace in the
Custom Server API Reference.
This creates a SetDate
step with the new date selected by the user during a recording session.
Note: When developing support for a Silverlight control, the
OnMessage
method would return RECORD_HANDLED, indicating
that the custom server handled this message and it does not have to be passed on
to any other event handlers. For details, see the Mercury.QTP.Slv.CustomServer namespace in the
Custom Server API Reference.
Implement the GetWndMessageFilter
method to specify the level of Windows messages to be handled by the custom
server.
|
CTL_MsgFilter GetWndMessageFilter()
{
return CTL_MsgFilter.CTL_MSGS;
}
|
In this tutorial, all children of the control are regarded as
part of the control. Therefore, it is sufficient to return CTL_MSGS, and handle messages intended only for this
control.
If some of the control's children were treated as separate test
objects, but you still wanted the control to handle events that occurred on
these children, you could implement GetWndMessageFilter to return CHILD_MSGS.
Deploy and Test Your Support for Recording
You have now completed the design of the support for the WPF
Calendar control.
In this section, you deploy the custom server again and test
the support that you designed for recording operations on the Calendar control.
Comments
Post a Comment