HOW TO CLICK IN BUTTONS WITHOUT RECORDING ACTIONS

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. See the general strategy from https://automatedtestingtools.wordpress.com/2016/04/19/strategy-to-get-automated-testing-without-recording-actions

In the next class is shown a method to click in buttons such as ok, cancel, confirm, exit….

public static WinButton WinButton;

private static Dictionary<string, WinButton> objDict = UiTestWinButtonDict.UiTestWinButton();

public static void DoubleClickInButton(string tableKey)
{
	WinButton winButton = objDict[tableKey];
	if (winButton.WaitForControlReady(2000))
	{
		Mouse.DoubleClick(winButton);
	}
	else
	{
		Assert.Fail("The button is not ready or does not exist.");
	}
}

As it is shown in the previous code the UI Control of the grid parent is stored in a dictionary. Please see the next post for more information of how to store UI Controls in dictionaries: https://automatedtestingtools.wordpress.com/2016/03/28/how-to-create-dictionaries-to-add-ui-controls

HOW TO SET VALUES IN WINEDIT BOXES

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. See the general strategy from https://automatedtestingtools.wordpress.com/2016/04/19/strategy-to-get-automated-testing-without-recording-actions

In the next class is shown a method to set data in a box using SetProperty():

private static Dictionary<string, WinEdit> objDict = UiTestWinEditDict.UiTestWinEdit();

public static void SetValueInWinEdit(string textComments, string tableKey)
{
	WinEdit winEdit = objDict[tableKey];
	if (winEdit.WaitForControlEnabled(2000))
	{
		winEdit.SetProperty("Text", textComments);
	}
	else
	{
		Assert.Fail("The next value cannot be written in the box: " + textComments);
	}
}

As it is shown in the previous code the UI Control of the grid parent is stored in a dictionary. Please see the next post for more information of how to store UI Controls in dictionaries: https://automatedtestingtools.wordpress.com/2016/03/28/how-to-create-dictionaries-to-add-ui-controls

HOW TO CLICK IN CELL ELEMENTS FROM A PARENT GRID

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. See the general strategy from https://automatedtestingtools.wordpress.com/2016/04/19/strategy-to-get-automated-testing-without-recording-actions

Therefore, the best option is to get Coded UI controls from the parent control and to get from it all the children items using the Add a new control to the UIMap tool (see https://automatedtestingtools.wordpress.com/2016/04/11/how-to-capture-ui-control-with-coded-ui-test-builder-without-recording-actions).

In the next example a table grid is presented with two columns.  The strategy to follow is to get only the squared UI Control and from it get both all the cells of the grid.

tablegrid

A method to click in any cell of the grid from the parent element is shown in the next class. The key point is to use first GetCell():

private static Dictionary<string, WinTable> objDict = UiTestTableGridDict.UiTestGridTables();

public static void ClickInCellElement(int row, int colum, string dictKey)
{
	WinTable table = objDict[dictKey];
	UITestControl children = table.GetCell(row, colum);
	if (!children.Enabled)
	{
		Assert.Fail("The cell element is not enabled or does not exist.");
	}
	else
	{
		Mouse.Click(children);
	}
}

As it is shown in the previous code the UI Control of the grid parent is stored in a dictionary. Please see the next post for more information of how to store UI Controls in dictionaries: https://automatedtestingtools.wordpress.com/2016/03/28/how-to-create-dictionaries-to-add-ui-controls

How to get combo box items 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. See the general strategy from https://automatedtestingtools.wordpress.com/2016/04/19/strategy-to-get-automated-testing-without-recording-actions

Therefore, the best option is to get Coded UI controls from the parent control and to get from it all the children items using  the Add a new control to the UIMap tool (see https://automatedtestingtools.wordpress.com/2016/04/11/how-to-capture-ui-control-with-coded-ui-test-builder-without-recording-actions).

In the next example a combo box is presented with a list of countries.  The strategy to follow is to get only the red squared UI Control and from it get both all the countries items of the list.

combobox

A method to click in any list item of a combo box (for example Germany) from the parent element is shown in the next class. The key point is to use first Items.ToList():

public static WinComboBox ComboBox;

public static List GetElementsFromComboBox;

private static Dictionary objDict = UiTestComboBoxDict.UiTestComboBox();

public static void MouseClickInComboBoxElement(string nameComboBoxElement, string dictKey)
{
	ComboBox = objDict[dictKey];
	UITestControl elemeUiTestControl =
		ComboBox.Items.ToList().FirstOrDefault(element => element.Name == nameComboBoxElement);

	if (elemeUiTestControl != null)
	{
		Mouse.Click(ComboBox);
		Mouse.Click(elemeUiTestControl);
	}
	else
	{
		Assert.Fail("The next combobox element does  not exist: " + nameComboBoxElement);
	}
}

As it is shown in the previous code the UI Control of the combo box parent is stored in a dictionary. Please see the next post for more information of how to store UI Controls in dictionaries: https://automatedtestingtools.wordpress.com/2016/03/28/how-to-create-dictionaries-to-add-ui-controls

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 https://automatedtestingtools.wordpress.com/2016/04/17/how-to-get-menu-elements-from-the-parent-element
  • 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:

1

Uimap

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.

FuctionalActions

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 https://automatedtestingtools.wordpress.com/2016/04/15/how-to-get-menu-elements-from-the-parent-element).

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

2

TestCripts

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

Utilities

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 https://automatedtestingtools.wordpress.com/2016/04/11/how-to-capture-ui-control-with-coded-ui-test-builder-without-recording-actions).

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.

calculator

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)
                {
                    Mouse.Click(item);
                    foreach (WinMenuItem subMenuItem in item.Items)
                    {
                        if (subMenuItem.FriendlyName == subMenu)
                        {
                           Mouse.Click(subMenuItem);
                        }
                    }
                }                
            }
        }

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

  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.

2

  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.

3

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

4

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.

[1] https://msdn.microsoft.com/en-us/library/dd286726.aspx#VerifyingCodeUsingCUITGenerateAssertions

[2] https://msdn.microsoft.com/en-us/library/dd380782.aspx

 

How to create dictionaries to add UI Controls

Author: Alfonso Alarcón

In Coded UI projects of visual Studio (Enterprise, Ultimate or Premium versions) control data (properties and values)  on the different functionalities are saved in structures named UI Controls. Even though other possibilities are possible the UI Controls can be stored in dictionaries to be invoked in functional methods. The important point is to create a dictionary for each type of control. Therefore, it can be a dictionary for: ComboBox, MenuBar, TableGrid, WinButton or WinEdit but the list can be more extends depending of the application. The “Key” of the dictionary is a constant string and the “Value” is the type of the UI Control.

All types of UI Controls are inheritance of the class UITestControl. Therefore, it is possible to create the dictionaries with this class but if you need specific methods of a particular UI Control you must work with its class. For example, in the case of combo boxes, you need to work with the specific methods of the class WinComboBox. In this dictionary all UI Controls are stored in a dictionary named ComboBoxDict inside the method UiTestComboBox():

public static class UIDict
{
	public static Dictionary<string, WinEdit> UiDictA()
	{
		UIMap uiMap = new UIMap();
		Dictionary<string, WinEdit> winEditDict = new Dictionary<string, WinEdit>();
		winEditDict.Add("A",uiMap.UIaWinEdit);            
		return winEditDict;        
	}
}

More information related with this post in:

https://msdn.microsoft.com/es-es/library/xfhwa508(v=vs.110).aspx

https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.uitesting.uitestcontrol.aspx