Category: Visual Studio ALM

Coded UI – Finding Controls – Best Practices

In one of the previous posts I mentioned the ability to use parent-child relations in order to find controls, and in this article I’ll share my experience and what I find as best practice for finding controls.

  1. Always look for ID or Friendly Name. Everythig else try to avoid, especially Tag Instance.
  2. In case that element doesn’t have one of these two, find parent that have.
  3. If both elements – child and parent doesn’t have any of these two, find parent that does

Why is finding ID or Friendly Name important? Simply, ID should be always unique, and Friendly Name is usually unique at least on current page.

Example:

<div id=”ihaveid”>
	<div> <!-- child1 – first child of div with id -->
		<div> <!-- child2 – first child of child1 -->
			<span>This is what I want to find</span> <!-- child3 – first child of child2 -->
		</div>
	</div>
</div>

So, logic here is to find child inside of child until you get where you want to be.

public HtmlDiv FindDivById(UITestControl parent, string id)
        {
            var parentdiv= new HtmlDiv(parent);
            parentdiv.SearchProperties.Add(HtmlDiv.PropertyNames.Id, id);
            return parentdiv;
        }
		
var parent = FindListById(browser, "ihaveid");
var child1 = parent.GetChildren()[0];  // 0 is 1st child, 1 is 2nd child, ….
var child2 = child1.GetChildren()[0]; 
var child3 = child3.GetChildren()[0];
Mouse.Click(child3);    // this is in case that you want to click on it, but logic is same for any other operation

As you see, logic is very simple. Find nearest parent element that have unique control(s) and search for child elements inside of it.

In my example elements used are div and span, but really you can use it in every combination with lists, paragraphs, …

Coded UI – Hand Coding vs. Recording

There are a lot of articles, blog posts and discussions on the web about Coded UI best practices.
Is recording better? Or is it better to write your own code? Or a combination of both? These are just some of the common questions which we can run into, especially from newcomers to Coded UI.

Main question you should ask yourself is – What is my goal?

If your goal is to create simple automation which will be executed only from your machine and no need to be consistent in any way (something like “one-time” testing), then my answer is recording.

Why? Because in half an hour or less, you will have created your automated test cases.

If your goal is to create complex and reliable automation which will be executed from various VMs or local machines, various resolutions, screen sizes, etc. … then you should definitely write own code.

Why? Because in that way you will have complete control over your automation. You will decide which control(s) will be searched (my suggestion is to look for ID first, because it should always be unique). When you cannot find ID for any specific control (submit button or whatever), my suggestions is to use parent – child relationships. Of course, you first need to find a parent with ID or some unique control. Will spend more time on this in separate post, but please look to the following example for better understanding.

public void EnterValueFriendlyNamebyParentDiv(UITestControl parent, string id, string Fname, string value)
    {
// first we search for parent div that have ID
        var parentdiv = new HtmlDiv(parent);
        parentdiv.SearchProperties.Add(HtmlDiv.PropertyNames.Id, id);
// now searching for input field inside of that div with specific friendly name
        var enterv = new HtmlEdit(parentdiv);
        enterv.SearchProperties.Add(HtmlEdit.PropertyNames.FriendlyName, Fname);
// enter whatever is defined as value
        enterv.Text = value;
    }

One more powerful fact that supports hand-coding is C#. Every method/assertion/whatever-you-need that doesn’t exist as part of Coded UI, can be programmed with C#. Basically there is no way that you cannot find any control, or handle any error, or solve any problem, if you know C# basics, you can solve it. Otherwise consider Google as you best friend. C# has a big and open community and will offer you a lot of answers for possible problems.

Why is recording not reliable? When you use recording and Coded UI cannot find any unique controls, it will use points (X, Y coordinates). That is the worst possible way to find controls, because on different resolutions/screen sizes Coded UI will hit the wrong point on the screen. Only if you’re lucky, during execution it will find controls on your machine (machine on which test is recorded). Also, beside points, another bad way to find controls is Tag Instance, which Coded UI like to collect during recordings. Tag Instance is bad because it can be generic.

Combination of recording and hand coding.

Again, whether this is the best choice for you depends on what you want to achieve. One thing that I would like to point out is to be careful with editing of recorded actions. When you record some action and you want to edit something related to that action in UIMap (add search control, for example) you need to know that after your next recording all your editing will be lost, because Coded UI reverts everything to its originally generated state after every recording.

Conclusion

No, Recording is not useless, it has its own uses over hand-coding. It takes less time for creation, and doesn’t require any coding background. However, as I said, if you want reliable automation which will not break without reason in more than 50% of cases, you need to go deeper and learn some basic coding.

Coded UI – Use Unit Tests instead of Assertions

Coded UI offers Assertions to use as the main method for verification points and compares in our tests, which works fine, but it can be very slow, depending on amount of controls (html tags) that your application has.

Instead of classic assertions, my suggestion is to use “unit tests”.

What does this mean?

Basically instead of Assertion, just try to find the control as you are doing when you want to click on something or to enter anything.

Example:
You have a shopping cart and you want to verify if the price is correct.

Instead of

var tablecell = GetShoppingCartCellByRowColumn(browser, "DataTables_Table_0", 1, 3);
Assert.AreEqual("$29.99", tablecell.InnerText);
//GetShoppingCartCellByRowColumn is method that searches table by ID and then specific cell by row and column.

Use

var tablecell = GetShoppingCartCellByRowColumnAndInnerText(browser, "DataTables_Table_0", 1, 3, "$29.99");
if (tablecell.Exists){
    //Happy message
    }
else {
    //Sad message
    }

Conclusion

In this example we are looking for a specific cell with a given value, instead of finding the cell and then comparing values. If the tool doesn’t find it, it will throw a custom message.
This approach simulates Assertion, but works much faster, and gives you more power for confirmation/error messages handling.