Strategy to get automated testing without recording actions

Author: Alfonso Alarcón

Many times the usual work environment in large automated testing projects is under a continuous integrated development process. This implies that both development and automated testing processes are done in parallel.  In this scenario the most common problems are related with test cases that fail as a consequence of changes in the functionality (by part of developers) and not as a consequence of finding bugs in this functionality (that is the final purpose). For this reason providing a good treatment and maintenance of controls (different structures that conforms the functionalities of an application or web such as comboboxes, menubars, tablegrids, buttons, winedits, among others) is the key point.

The most extended way of working (and the easiest) in automated testing is recording actions. All the specialized software in this field such as Visual Studio, HP UFT, Ranorex Studio, SeeTest, Squish… are their own recording tools. But this strategy presents manifest problems, basically:

  • Maintenance: When we have a great quantity of recorded actions they must be reviewed one by one when changes in the application are common.
  • Unproductive recording: In some situations controls are recorded one by one providing a great quantity of recorded actions. For example, if you want to get the information of a menu (for example, the menu file in an application) the most easily solution is to record all items one by one spending a great quantity of time. See the post
  • Unproductive strategy: Usually in our daily work we focus our attention only in the part of the functionality under test without any global vision.

To surpass these problems it is recommended a strategy based on change the way of thinking for understand the software that you are testing from a general vision. The strategy has a general purpose and can be used for all specialized software.  It is based on the next points:

  • Improve the maintenance: Get the information from the parent and from it obtain all the children’s. With this way of working you only need to capture the UI control of the parent of the menu and from it to get all the items of the menu reducing the spending time (in reference to recording action method) and increasing the maintenance.
  • Avoid recording actions: Store the information related with controls instead of record it. See post How to get UI Controls with Coded UI Test Builder without recording actions
  • Smart strategy: First analyze how many controls types have the UI and next start working.

Also, to support the strategy proposed it is suggested to provide a layer structure since this way of working provides the next advantages:

  • The division of the solution into separate layers improves the maintenance.
  • Changes in one part of the solution should impact in other parts minimally.
  • Certain components must be reusable in different modules.

Therefore, the most basic structure can be schematized as:



The lowest layer of abstraction, it is the basis of the system. It represents a Map of the user interface (UI) ordered in a tree structure. Here, it is to possible visualizing the UI Controls.


This layer presents a set of classes to deal with UI Controls stored in UIMap. Whether with or without recording actions the associated information about controls is stored in the UI Control Map (see post How to get UI Controls with Coded UI Test Builder without recording actions). With the strategy presented here we don’t have created the method that manipulates the action (for example click a menu item) and therefore the creation has to be done a posteriori (see post

For example in the particular case of .net in Visual Studio, the layer structure can be:



It is the most external layer where are implemented the test cases using methods created basically in the FunctionalActions layer.


Here, different classes that can be used transversally in all layers are created. Here, it is recommended to create a class to store the constants that can be used as key in dictionaries, classes to access to XML files, etc….

This post is only an approach to review a strategy  that is well known in automated testing from a general point of view, independent of the technology used. To complete the explanation other posts have been provided and will be provided in the future.


How to get menu elements from the parent element

Author: Alfonso Alarcón

In Coded UI Test solutions of visual Studio (Enterprise, Ultimate or Premium versions) is recommendable to optimize efforts avoiding recording actions when a large numbers of elements must be recorded. Therefore, the best option is to get the Coded UI controls from the parent control and to get from it all the children items using  Add a new control to the UIMap tool (see

For example in a typical calculator the menu bar has a set of menus (View, Edit and Help) the strategy to follow is to get only the squared UI Control and from it get both all the menus and related items of each menu.


In the next class is provided how to click in an element of a menu. Therefore, if you want to click for example in the Programmer item of the menu bar the key point is to use GetChildren():

        public static WinMenuBar MenuBar;
        private static Dictionary<string, WinMenuBar> objDict = UiTestMenuBarDict.UiTestWinMenuBar();
        public static void MouseClickSubMenuItems(string menu, string subMenu, string dictKey)
            MenuBar = objDict[dictKey];

            foreach (WinMenuItem item in MenuBar.Items)
                if (item.FriendlyName == menu)
                    foreach (WinMenuItem subMenuItem in item.Items)
                        if (subMenuItem.FriendlyName == subMenu)

How to get UI Controls with Coded UI Test Builder without recording actions

Author: Alfonso Alarcón

One of the most powerful technologies to work with automated testing is the Coded UI Test Builder included in the Enterprise version of Visual Studio 2015 (previously Premium and Ultimate Visual Studio versions) [1, 2]. It presents the well know recording tool to get automated testing but other procedure can be follow to save efforts and improve the maintenance in large automated testing projects. It follows the Add a new control to the UIMap tool. In the next a set of points to get UI Controls with this tool are presented:

  1. The first step is to create a Coded UI Test solution in Visual Studio
  2. In the created solution go to uitest (right button) and Edit With Coded UI Test Builder


  1. Here, it is show the two principal tools to work with Visual Studio in automated testing:
    1. Recording tool marked with A in the next screenshot.
    2. Add a new control to the UIMap tool marked in B in the next screenshot. As commented, the strategy presented here is based on get UI Controls with this second. To work with it you must apply it on the desired control in the UI of the application or web.


  1. Next add the captured data to the UI Control Map by means of To Add a new control to the UI Map marked with C in the next screenshot. Use the option copy to clipboard (D in the screenshot) to get the text of the UI Control and apply it in the code later.


  1. In UIMAP.uitest go to UI Control Map where the details of the UI control are shown.


A last comment, the name of the stored UI Control can be changed. As the number of stored UI Controls is increased the difficulties to understand the meaning  of them increases. Therefore it is a best practice to rename UI Controls in function of its content.