Significance of Window Titles in Coded UI Test Playback

Significance of Window Titles in Coded UI Test Playback

  • Comments 2

The control search in Coded UI Test playback is essentially a breadth first search. For extension plugins that have in-built search capability, the plugin writer can implement its own search logic. What typically remains the same is the way the search is done for the top level window of the application.

 Consider a top level window UI object such as

       <TopLevelWindow ControlType="Window" Id="UICalculatorWindow" FriendlyName="Calculator" SpecialControlType="None" SessionId="36635974">

          <TechnologyName>MSAA</TechnologyName>

          <WindowTitles>

            <WindowTitle>CalculatorX</WindowTitle>

            <WindowTitle>CalculatorY</WindowTitle>

          </WindowTitles>

          <AndCondition Id="SearchCondition">

            <PropertyCondition Name="Name">Calculator</PropertyCondition>

            <PropertyCondition Name="ControlType">Window</PropertyCondition>

          </AndCondition>

          <Descendants>

                <UIObject ControlType="Button" Id="UISubtractButton" FriendlyName="Subtract" SpecialControlType="None">

                  <TechnologyName>MSAA</TechnologyName>

                  <WindowTitles>

                    <WindowTitle>CalculatorX</WindowTitle>

                    <WindowTitle>CalculatorY</WindowTitle>

                  </WindowTitles>

                  <AndCondition Id="SearchCondition">

                    <PropertyCondition Name="Name">Subtract</PropertyCondition>

                    <PropertyCondition Name="ControlType">Button</PropertyCondition>

                  </AndCondition>

The top level window has a Name property value “Calculator” and a list of window Titles “CalculatorX” and “CalculatorY”. The recorder auto-generates these window titles for scenarios where the title of the application top level window changes across different actions performed on the controls within this window.

During the playback search, in the first phase, the playback enumerates through all windows under the desktop to match for a window title “Calculator” i.e. the Name property value in the above UICalculatorWindow object.
If it fails to find any window with title “Calculator”, it then moves to the second phase where it tries to match any window with title “CalculatorX” or “CalculatorY”.

In each phase, a similar heuristic is applied i.e. first search within Maximized window, then search within Minimized windows (depending on the Playback.PlaybackSettings.SearchInMinimizedWindows) and finally apply smart match (depending on the Playback.PlaybackSettings.SmartMatchOptions)

Now consider an application where the window title changes by performing some navigation click actions on hyperlinks in the left pane (which causes the right pane’s content to refresh). Assume the user is hand-coding the test scenario and has statically added all the hyperlinks in the left pane to the UIMap. All these hyperlink controls and the top level window would have been auto-generated with only one WindowTitle i.e. the title of the window when the controls were captured in UIMap (say, TitleA) 

If the user runs through the test scenario and has an action on the any of these hyperlinks while the window title has actually changed (from TitleA to TitleB), the search will fail.  To fix this, the user needs to manually append the TitleB to the list of window titles for the hyperlink’s top level window in the UIMap.

Note, if you are in VS2011 RC bits or later, it is not required to update the window titles for each of the inner hyperlink controls. Just the top level window’s window title list update will suffice. (This was a product bug that has been fixed in VS2011 RC). Without this fix, the user would have required to update the window titles of all the inner hyperlink controls to include TitleB.

 

Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post
  • Hi Tapas,

    Thanks for the detailed explanation. It is very informative.

    I also follow the way of finding windows using title with "Contains" operator with static text. But sometimes I saw that CodedUI is not using this "Contains" operator while searching for controls (What I have observed is the Top level container)

    Above scenario can be reproducible using the "Locate UI Control" from the UI Map using visual studio as well as during test automation run.

    I have confirmed this by adding the new window title to the top level window object, then it started recognizing though it was matching the first criteria itself. (As below)

    Top Level window title: Journal Voucher (1-ceu) - 1008

    Search criteria given was "Name" Contains "Journal Voucher"

    During playback, window was having a new title as "Journal Voucher (1-ceu) - 1009"

    This time CodedUI did not recognise the control! Test case got failed! I tested this again with "Locate UI Control" feature from VS 2010. Result is the same.

    When I added the latest title to the list of title in (Designer/code) and tried to "Locate UI Control", it is picking up! Any reason why "Contains" operator is not working here?

    To make this "Contains" clause work, is it mandatory to set the SmartMatchOptions?

    Dynamically changing titles is driving automation crazy. I had to go back to the XML version of UI Map, change the recorded properties to "Contains" clause to enable recongnizing controls.

    Even then, sometimes, controls are not found! So, to fix this is enabling SmartMatchOptions is the only option?

    Thanks,

    Praveen

  • Thank you very much for your post.

    Is it possible to disable completely recording the Window Titles (when recording objects)? Because a window title can be dynamically generated per an environment.

    (I am using VS2013 )

    Thanks.

Page 1 of 1 (2 items)