Can we programmatically update locators on UI Change in UI test automation?

Question

I have been working in test automation for the last 10 years. The problem that keeps coming up and surprisingly is still unresolved is:

Can we programmatically update locators on UI Change in UI test automation?

What I mean is, automation teams need to run automation suites periodically, and many test scripts fail because of locator changes, not because of Application changes.

Can we make a general algorithm to update an locator automatically based on some structure of the DOM or some other logic?

By doing that, we could run that piece of code before the actual automation suite, in order to identify and isolate locator issues.

This way we can remove unnecessary overhead of running a large automation suite and analyzing it painfully only to find that all we found are locator changes, not any application issues. And finally manually updating all the failed locators with new ones using tools like Developer tools/firebug to find out new ones and manually changing them in the code which is generally the case with most of automation teams.

Has anyone worked with/implemented any solution for such situations?

Answer 1

I currently work on a solution for exactly this problem (well, more the Problem of not existing identifiers but unknown ID´s are as good as non existing).

The idea is to use Seleniums getCurrentURL() method to get the source code, use a HTML parser library like JSoup to split it into nodes and add an dummy class signed with a trigonometric identity calculated from it´s position on the Screen (a calculable constant on the application I work on since the PM's are quite adamant on not messing with the UI, might not work for you but that´s where your creativity `comes into play) to every single node and passing it into the Website using the JavaScriptExecuter class.

This makes it therefore easy to locate the element using findElement(By.className()) but has a tendency of breaking Javascript in the side in course of the passing through JS process since it needs to be passed as an inline Script and therefor any " needs to be replaced with an '. Since HTML is often messy this can end in dead functions falsifying your results.

I don't think that I need to tell you that this is a very bad idea to do and only feasible in absolute emergencies where anything else won´t work (and I'm talking about the "I prayed to the gods of chaos and sacrificed a lamb over my keyboard" kind of anything). I can provide the code I currently have if you want to but I won't take any responsibility for the world ending or your Test breaking (both are legit possibilities) because of it.

Answer 2

The application code should use the same locator as the test code.

In stead of centralizing the locators in POM's I would also centralize things as Labels and ID's in shared code between tests and applications. Meaning the POM's locators would get their data from a shared reference file.

You need to make sure you use a front-end framework where you have enough control over the naming of the DOM objects and its attributes.

If you have a localized application you would already have something like this for all the labels anyways.

I have created some proof of concepts for this at my previous employer, but as I mostly work on legacy applications its hard to implement structurally.

Answer 3

My answer to this is to write robust locators that are not affected by other UI changes. They should be unique but not overly specific.

So instead of
div div div span table tr tr td td input#last_name

use
input#last_name
or
form.new_user input#last_name

which will be more robust and allow the overall structure of the page to change

dev and ui have the same need for unique identifiers for both application code and also css styling so you'll want to work with them on a common approach when possible.

You do need to examine any change that makes the test fail and I'm not aware of any process that could automate that.
Now if id or name are being changed then you need to actually co-ordinate that with dev/ui. Or have them update the tests - ideally the page object definitions rather than the test code.

You also need to be sure to have pages start in the same condition and this means having a ui test database which is reset for each test. When you mention "What I mean is ,automation teams need to run automation suites multiple times periodically, and many test scripts fail because of locator changes" it seems that you do not have that guaranteed 'before' state in your tests so I would examine you setup-teardown processes. Your test database should be different, for example, from staging. It should be empty for each test and each test should setup all the data it needs including reference data. This can be quite a challenge for soem organizations particularly older and larger organizations.