How to handle Changing Control IDs in Coded UI tests

I am only starting with CodedUI now, but I did a lot of UI Automation using different products before and using the same technology (MSUIA etc.). So this should apply here as well.

Each control has several properties, like name and automationid to name the most important ones. If you are automating a UI that is your own (you code/build it yourself) you should always attempt to give a unique automationid to each control, that will make your life a lot easier when automating. Name often is a bad option, since it frequently changes when you have a different language version of a program.

Since in that case you do not have the source and cannot influence the values it reports, you have to work with what is given. Still, even though CodedUI recorder will choose any property it sees fit, you can change the search criteria yourself by changing the UIMap.uitest for each element found:

This probably will take some time getting used to.. especially for more complicated UIs where elements have similar properties, also for dynamic UIs, etc.

By the way, the products I was using earlier on directly were working with AutomationElements, and here you have the full power to select and do what you want - even though with a high maintenance and start cost. (Ok, so it is generally very time consuming - and will always be more time consuming than using any ready solution like VS Coded UI.)

One more easy solution also is to simply go by coordinates (relative to some known controls, like main window or a tab group), this also will work 99% of the time and bring you to your goal that much quicker.

Ok, answering your concrete questions

1) if that is what I think it is, they are generated at runtime and there really is no relying on them

2) When going lower level (like AutomationElement) you can search whole trees. Still, that will typically make the search rather slow as well - not much faster then if you get the whole tree yourself and traverse it

3) You can mix anything you want. Actually, you can even convert handles to AutomationElements to Controls (at least for most standard controls). So you could use any technology, like Win32 SDK, to traverse the tree. Actually, all GUI trees in all technologies are similar - though not the same. And few people coding seem to adhere to any standards.. at least that is my experience.

4) Using a variation of technologies, coordinates (actually, I even used screenshots) etc you can achieve almost everything. It takes a lot a lot of time though. Getting the basics right during development and taking feedback from UI test developers into account can greatly help speed up later testing. Simplest example: whether an application paints "all ok" on the screen or whether there is a control that can reach that has a name property that says "all ok" - second solution will be a lot better for the automation guy.

Also, for more complicated UIs, if you are in a corporate environment, have some money and want to spend a lot of time on UI tests anyway, I suggest a product like Ranorex, SilkRunner and the like. I worked with a Ranorex Eval for a few days and (after some getting used to it) could navigate UIs that very rather difficult to navigate myself beforehand.