Sunday, 9 October 2011



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.

  1. Run the sample WPF Calendar application and study its behavior 

    1. Double-click the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file. The Calendar application opens.









      This application contains 3 controls:

      • A calendar display area with buttons: Microsoft.Windows.Controls.Calendar

      • A text label: System.Windows.Controls.TextBlock

      • An edit box displaying the selected date: System.Windows.Controls.TextBox

    1. Study the application's functionality.

      • You can click the right and left arrows to go the next or previous month.

      • You can select a date in the calendar by clicking on the relevant day of the month.

      • You can view the selected date in the text box.

  1. Use the Object Spy in QuickTest to see how QuickTest recognizes the controls in the Calendar application

    1. Open QuickTest.

    2. 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.

    3. Run the Object Spy  and spy on the WPF Calendar.
    4. 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.

  2. Learn the Calendar control using QuickTest, adding it to an object repository 

    1. Open the Object Repository

    2. Click the Add Objects to Local button

    3. Click on an area in the calendar.

    4. Repeat steps b and c on different areas of the calendar.
    5. 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.

  3. Record a test on the Calendar control 

    1. Click Record.

    2. Click on different areas in the calendar.
    3. 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.

  4. 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
Open Microsoft Visual Studio 2008 and click New Project. The New Project dialog box opens:



  1. Select the Visual C# Windows project type and the QuickTest WPF CustomServer template, and click OK.
  2. 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.

  3. Enter CalendarSrv as the project Name, and click OK. The WPF/Silverlight Custom Server Setup dialog box opens.

  4. 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.
  5. In this tutorial:

    • 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.
    • 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).

  6. Click OK.

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.


<?xml version="1.0" encoding="UTF-8"?>

<Controls>

<Control Type="Microsoft.Windows.Controls.Calendar" MappedTo="MyWpfCalendar">

<CustomServer>

<Component>

<DllName>CalendarSrv.dll</DllName>

<TypeName>MyWpfToolkit.CalendarSrv</TypeName>

</Component>

</CustomServer>

</Control>

</Controls>



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.

  1. Open the MyWpfToolkitTestObjects.xml file.
  2. 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.

  3. 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:


    <TypeInformation AddinName="WPF" PackageName="MyWpfToolkit" >

    <ClassInfo Name="MyWpfCalendar" BaseClassInfoName="WpfObject" DefaultOperationName="SetDate">

    <IdentificationProperties>

    <IdentificationProperty Name="devname" ForDescription="true" />

    <IdentificationProperty Name="devnamepath" ForAssistive="true"

    AssistivePropertyValue="1"/>

    <IdentificationProperty Name="regexpwndtitle" ForAssistive="true"

    AssistivePropertyValue="2"/>

    <IdentificationProperty Name="x" ForVerification="true" />

    <IdentificationProperty Name="y" ForVerification="true" />

    <IdentificationProperty Name="is_today_highlighted" ForVerification="true"/>

    </IdentificationProperties>

    <TypeInfo>

    <Operation Name="Next" PropertyType="Method"/>

    <Operation Name="Prev" PropertyType="Method"/>

    <Operation Name="SelectedDate" PropertyType="Property_Get" >

    <ReturnValueType>

    <Type VariantType="VT_BSTR"/>

    </ReturnValueType>

    </Operation>

    <Operation Name="SetDate" PropertyType="Method" >

    <Argument Name="Date" IsMandatory="true" Direction="In">

    <Type VariantType="VT_BSTR"/>

    </Argument>

    </Operation>

    </TypeInfo>

    </ClassInfo>

    </TypeInformation>

  4. You have now defined:

    • 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. 

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: 


  1. Copy the MyWpfToolkitTestObjects.cfg file to <QuickTest installation folder>\dat\Extensibility\WPF.

  2. In the <QuickTest installation folder>\dat\Extensibility\WPF folder, create a folder named MyWpfToolkit.

  3. 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: 


  1. After you deploy the toolkit support set, open QuickTest.
  2. 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.)

  3. Select the check box for MyWpfToolkit and click OK. QuickTest opens and loads the support you designed.

  4. 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.

  5. 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.

  6. Run the sample control by opening the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file.
  7. 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.

  8. 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").
When you type the period, IntelliSense displays all of the operations available for the MyWpfCalendar test object class. This includes operations inherited from WpfObject, and ones that you defined in the test object configuration file.

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.

  1. 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.
    • 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.

    • The class definition includes the list of interfaces it will implement: IRecord, ICalendarRun, IComponentDetector, ICalendarProperties.

  2. In your project, add a reference to <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WPFToolkit.dll.
  3. 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.

  4. In Calendar.cs, add a using Microsoft.Windows.Controls; statement. This enables IntelliSense for the Microsoft.Windows.Controls.Calendar control type in Visual Studio.

  5. 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;

    }

    }


  6. 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.
  7. 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.

    1. Locate the ICalendarProperties interface definition in the CalendarSrv.cs file.


      [CustomPropInterface()]

      public interface ICalendarProperties

      {

      object MyCustomProperty

      {

      get;

      }

      }


    2. Replace the example object MyCustomProperty with bool is_today_highlighted to complete the interface definition.

    3. Locate the interface implementation in the CalendarSrv class:


      public object MyCustomProperty

      {

      get

      {

      return null;

      }

      }


    4. Modify the example implementation to retrieve the value for the is_today_highlighted identification property:


      public bool is_today_highlighted

      {

      get

      {

      return MyCalendar.IsTodayHighlighted;

      }




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.

  1. 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.

  2. Run the sample control by opening the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file.
  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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).

  8. 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.

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.

  1. Locate the ICalendarRun interface definition in the CalendarSrv.cs file:


    [RunInterface()]

    public interface ICalendarRun

    {

    void MyRunMethod();

    }


  2. 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;

    }


  3. Locate the interface implementation in the CalendarSrv class:


    public void MyRunMethod()

    {

    }


  4. Replace the MyRunMethod() example with the following implementation of the Calendar-specific methods and property:



  5. 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.

  6. Add a using System.Windows.Media; statement to the CalendarSrv.cs file and then add the following helper functions:



  7. private void RaiseButtonClickEvent(Button button)

    {

    if (button != null)

    {

    RoutedEvent e = Button.ClickEvent;

    RoutedEventArgs arg = new RoutedEventArgs();

    arg.RoutedEvent = e;

    button.RaiseEvent(arg);

    }

    }





    private DependencyObject GetDescendantByName(DependencyObject parent, string name)

    {

    if (parent == null)

    return null;

    int count = VisualTreeHelper.GetChildrenCount(parent);

    for (int i = 0; i < count; i++)

    {

    DependencyObject child = VisualTreeHelper.GetChild(parent, i);

    if (child is FrameworkElement)

    {

    if ((child as FrameworkElement).Name == name)

    return child;

    }

    if (child is FrameworkContentElement)

    {

    if ((child as FrameworkContentElement).Name == name)

    return child;

    }

    child = GetDescendantByName(child, name);

    if (child != null)

    return child;

    }

    return null;



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.

  1. 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.

  2. Run the sample control by opening the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file.

  3. 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.

  4. 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.)

  5. 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:

  1. 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()

    {

    }


  2. Declare your event handler and implement RecordInit to register it to the control.


    private EventHandler<SelectionChangedEventArgs> _h;

    public void RecordInit()

    {

    _h = new EventHandler<SelectionChangedEventArgs>(OnSelectedDatesChanged);

    UtilityObject.AddHandler(MyCalendar, "SelectedDatesChanged", _h);

    }

  3. 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.

  4. 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.

  5. Add the OnSelectedDatesChanged event handler implementation:


    private void OnSelectedDatesChanged(object sender, System.Windows.Controls.SelectionChangedEventArgs e)

    {

    UtilityObject.Record("SetDate", RecordingMode.RECORD_SEND_LINE, MyCalendar.SelectedDate.Value.ToShortDateString());

    }

  6. This creates a SetDate step with the new date selected by the user during a recording session.

  7. Implement the OnMessage method as follows, to support recording Prev and Next operations:


    public void OnMessage(DependencyObject o, int msg, int wParam, int lParam)

    {

    if(o is Button && msg == 0x201) // WM_LBUTTONDOWN

    {

    string name = (o as Button).Name;

    switch (name)

    {

    case "PART_NextButton":

    base.UtilityObject.Record("Next", RecordingMode.RECORD_SEND_LINE, null);

    break;

    case "PART_PreviousButton":

    base.UtilityObject.Record("Prev", RecordingMode.RECORD_SEND_LINE, null);

    break;

    }

    }

    }

  8. 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.

  9. This step is only necessary when developing support for Silverlight controls.
  10. 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.

    1. 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.

    2. Run the sample control by opening the <WPF and Silverlight Add-in Extensibility SDK installation folder>\samples\WPFExtCalendarSample\Application\WpfCalendar.exe file.

    3. 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.  
















0 comments:

Post a Comment

Bookmark Us

Delicious Digg Facebook Favorites More Stumbleupon Twitter