How to avoid broken CSS path/XPath references in automated UI tests?

Question

I have a set of TestNG tests that I use to test a web based UI.

For example a typical test would click on different menus and buttons and assert that the outcome is the one we expect.

These tests also use Selenium in the background. I have my test in one class, and a model of the web page in another class.

To get a reference to a UI component (button, menu etc) in the web page I use a CSS or XPath selector. This is hard coded in the model class. To get an object representing a UI component I call a get method in the model class which returns an object for the UI component using the css selector. Then using that object I can click, select, deselect or do any operation on the component.

This all works fine except if the css selector changes.

Is there a way to avoid this?

I was thinking if I could repeat a test manually by going through each step or click, and record the css selectors for the elements used this would be quicker than debugging the test, finding out what the new element name is in the page/javascript manually and updating the model css selectors.

Or is there a way of linking the web page development and automatically updating the model code for the change in the page, so that the change wouldn't break the test?

Thanks!

Answer 1

Something I've done in the past to make maintenance of paths/selectors easier is to keep them in one, or many, files as strings, which are imported by your model. This file of path/selector strings might be a properties file in Java. Have your development team own maintenance of these paths, so when they change the GUI, they also update this file.

Yes, this is one more thing that has to get done, but it does make maintenance of the automated tests just a little bit easier.

One caveat is that sometimes a GUI changes so that a control disappears, or changes types, and in those situations, a new locator will not help you.

Answer 2

I am not sure if there is any such tool exist but so far I know there is none. I know QTP has a build in feature where you can update the latest elements/recordings. But, no such mechanism in Selenium.

In terms of selector, ids always have been the best choice. That is what suggested by Selenium core team and all other automation engineers using it. See the suggestion made by SeleniumHQ. I would strongly agree with them since ids are to be unique(even sometimes I experienced the duplicate ids and that's usually developers fault) and there is no chance of breaking your test even if the location or such of the element changes which will (possibly) break other selectors such as xpath/css.

I also agree that there are some cases where ids are not possibly an option. In that case you will have to be really careful about writing the selectors. With an efficient selector you can avoid/minimize the chance of failure like this particular scenario.

As an example the absolute xpath for Google search input tag:

html/body/div[1]/div[3]/form/div[2]/div[2]/div[1]/div[1]/div[3]/div/div[3]/div/input[3]

You, however, need to avoid such selector and write one which does not depend on each and every tag or the structure of the html.

I can write one like as follows for the same element:

//*[@id='gs_htif0']

Same concept applies to cssSelector. Also, consider using xpath text based search, even though that should not the first choice.

Answer 3

If you create robust HTML with the relevant elements having meaningful ids and/or CSS classes, there will be very few changes to the UI where you need to adjust test selectors. (What kind of naming system you choose is up to you, what's important is that it should be systematic and it should reflect what the component means rather than how it should be displayed. So input200pxwidebold is not a good CSS class name, while mainMenuItem probably is.)

In general, if you find yourself having to adjust loads of unit tests to cover for even the most minor changes in the SUT (system under test), then the brittleness of your tests is an indication (or smell if you like) that the design should be improved.