How to handle changing control IDs in coded interface tests
I am mainly working on testing UI automation of a Windows based application using CODE studio visual interface, the problem occurs when and when the layout changes or some new control is added in the GUI and the control ID changes. As we can see in the screenshot that the typical hierarchy is restored by the CODE UI constructor which: -
Main Window → Window with Control ID → Actual Control.
So here are my questions related to this hierarchy and control ids?
1) How are these control IDs generated ?
a) I know there is some logic by which these control IDs are depending on the depth of the control in the GUI, but I am not able to find any consistent way to create them, for example in the images there are two buttons connect and help seems to be at the same GUI level, but still their control IDs are so different 1 and 5013 .
b) Are these control IDs generated by the UI encoder used in testing the environment or is there some logic on the side of product development or the code itself by which they are generated
2) Is there a way to skip this middle layer of the control id window and record and play back successfully. (As in my case, we have access to the logical name of all controls, which are themselves unique in nature, and we can get rid of those control IDs)
3) Plus Can we have a hybrid approach where we have two levels for almost all controls, but three levels for some special cases where its not possible to work with a boolean name or label and we explicitly require control IDs
4) Last but not least, how much of the available implementation of this type can be done in a testing environment , according to my knowledge, most of the access to controls should be done in a product development environment by adding some properties to the code itself, which can then be restored for testing using various tools such as CODE interface in a test environment. But for large-scale products, I don't think this is a good approach as it puts an additional burden on the development side, and it's like adding extra code to the product (for testing purposes only) that needs to be delivered to the customer.
Plz see the images below as a reference for clarity on my questions.
1st image shows the desktop GUI
2nd shows Computer: control properties recorded by CODED UI
3rd shows Connect Button Properties recorded by CODED UI
4th shows Help Button Properties written by CODED UI
source to share
I'm just getting started with CodedUI now, but I've done a lot of UI automation using different products before and using the same technology (MSUIA, etc.). So this should also apply here.
Each control has several properties, such as name and automationid, to indicate the most important ones. If you are automating a user interface that is your own (you code / create it yourself), you should always try to give each individual element a unique automation ID that will make your automation life easier. The name is often a bad choice as it changes often when you have a different language version of the program.
Since in this case you do not have a source and it cannot influence the values that it reports, you have to work with what is given. However, even though the CodedUI recorder will pick whatever property it sees fit, you can change the search criteria yourself by changing the UIMap.uitest for each item it finds:
It will probably take a while to get used to ... especially for more complex user interfaces where elements have similar properties, as well as dynamic user interfaces, etc.
By the way, the products I used earlier worked directly with AutomationElements, and here you have full opportunity to choose and do what you want - even with high maintenance and startup costs. (Ok, so it usually takes a long time and will always be more time consuming than using any out-of-the-box solution like VS Coded UI.)
Another simple solution is to just navigate by coordinates (relative to some well-known controls like the main window or a group of tabs), this will also work 99% of the time and will lead you to your goal much faster.
Okay, answering your specific questions
1) if that's what i believe they are generated at runtime and don't really rely on them
2) When you go to a lower level (like AutomationElement) you can search for whole trees. However, this tends to make the search rather slow, and also not much faster if you get the whole tree yourself and traverse it.
3) You can mix whatever you want. In fact, you can even convert descriptors to AutomationElements to Controls (at least for most standard controls). This way, you can use any technology like the Win32 SDK to navigate the tree. In fact, all GUI trees across all technologies are similar, but not the same. And few people code seem to adhere to any standards. At least that's my experience.
4) Using variations of technologies, coordinates (in fact, I even used screenshots), etc. you can achieve almost anything. It takes a long time though. Gaining the basics during development and getting feedback from UI test developers can greatly help speed up subsequent testing. Simplest example, whether the application is showing "everything is fine" on the screen, or is there a control that can reach that has a name property that says "everything is fine" - the second solution would be much better for the automation guy.
Also, for more complex UIs, if you are in a corporate environment, you have the money and want to spend a lot of time on UI tests, I suggest a product like Ranorex, SilkRunner, etc. I worked with Ranorex Eval for a few days and (after getting used to it for a bit) was able to navigate user interfaces that were very difficult to customize beforehand.
source to share