1

One of the major reasons for ui automation failure is locator changes which need to be constantly updated. What is best way to maintain locators so I don't have to update test automation code every time locators change.

Deepak Rai
  • 2,163
  • 3
  • 21
  • 36
irlatech
  • 67
  • 6
  • How often do your locators change? Your questions does not specify what the problem is. – vitaliis Jan 31 '21 at 03:58
  • its not the question on how often, but when they do its all the teams who are dependent on the locators need to be updated manually. I am sharing my Page object as an npm package/maven package for other teams who use our ui to create their automation. What I am proposing will help teams continue to use current version without needing to update their version for only locator changes. – irlatech Feb 01 '21 at 18:21

4 Answers4

0
  1. Create a common locator.json file for each ui which provides the locators needed to perform actions on the ui and is part of the ui asset which can be loaded by directly accessing the file using the domain and path
  2. Write unit/e2e test in the ui application to use the above locators so its always valid before changes get deployed
  3. When locators change only these tests need update and your actual e2e validations tests don't need update.

By using this approach, teams don't need to worry about the locator changes and can rely on this file for providing updated locators in every environment. It can be used in any automation script where locators are needed. Cross application ui automation execution becomes more reliable and avoids false negative.

Example locator json file: http://www.myappquality.com/asset/locators.json

irlatech
  • 67
  • 6
  • 1
    adding locators to different file is just adding more complexity to the framework you can keep it in same page object – PDHide Jan 30 '21 at 01:37
0

Best practice is to use the page object model. The core of this idea is that each page on your site is represented by a class in your test project. All locators for that page should reside in that class. All actions that a user might take on that page would be represented by a method in that class. So, when that page is updated on the site, you know exactly where to go to make changes... the corresponding class.

If each of your tests contain the locators, a page redesign involves searching for every test that touches that page and updating the locators. If you use page object model and the page is redesigned, you open up the class for that page, update the locators and you're done. What might be hours of work for method #1 would be a few minutes when using the page object model... and you won't mistakenly miss updating a test.

Some references
Page object models from selenium.dev
Using Page Objects to Organize Tests from protractortest.org

I also wonder if perhaps you are creating suboptimal locators and that is causing you to have to update locators more often than you should. If minor changes to the page are forcing you to update locators for elements that weren't directly affected by the updates, you probably are using XPaths copied from a tool rather than handcrafted ones. This can cause a LOT of unnecessary locator updates. If this is the case, I would suggest a lot of reading. Read lots of articles on how to create good locators. Avoid XPath locators in most cases. Look for elements with IDs, names, and the like and use those. Learn how to write CSS selectors... there's lots of good articles on the web covering that topic. XPaths are generally avoided by the Selenium contributors. They are slower, the syntax is much more complicated and verbose, and the support is not as good as CSS selectors. In general, XPaths should only be used when necessary... when you have to locate an element by contained text or perform some complicated DOM traversals.

If you can master those two things, your automation will be much cleaner, easier to read, and a LOT easier to maintain... and will need less maintenance.

JeffC
  • 22,180
  • 5
  • 32
  • 55
  • Yup I meant to use the locator file inside page object class ( as per what mentioned originally "It can be used in any automation script where locators are needed"). I have to share my page objects with other teams. If I have the locators in class I need to publish a new version and down stream teams have to be communicated about the change and update on their side. This solution is for locator changes I don't have to publish and remember to update the team and also having to maintain version for different environments. – irlatech Jan 30 '21 at 03:05
  • I guess I don't understand this approach. Why wouldn't you just have a single project that contains the page objects and the tests. Your team and any other team that was writing automation would just add tests to the single project. Now updates to the page objects are automatically "delivered" to all teams and fixes for your scripts would also fix other teams' scripts as well. – JeffC Jan 30 '21 at 04:28
  • If for some reason you are not allowed to have the various teams' tests in the same project (seems really odd and counter productive to me but maybe there's a good reason?), you could create a project that is nothing but page objects. Your teams' test project would pull in that project and then write automation. Other teams would have their own projects and pull in the page object project also. That way when updates are needed, you (or someone from another team) update the page objects project and then everyone pulls in the update and you keep all your tests separate. – JeffC Jan 30 '21 at 04:31
  • if the ui development is distributed across teams where each team knows only about the features they are working on and rely on lti contractors for passing data across and launching ui from another team [link](shorturl.at/bozOW), end to end automation becomes a challenge when each team has their on development, release cycle and maintain their own environments. – irlatech Jan 30 '21 at 17:43
  • Using page objects from the other team will help but when there is continuous deployments happening, there is a need for page objects to be updated every time and most of the time locators are what change. I am saying use page objects but maintain locators used in page object as part of UI asset which gets deployed when UI changes. Probably you have not faced this issue but someone who has worked in this situation I believe this will help. – irlatech Jan 30 '21 at 17:44
0

Read this What is the Page Object Pattern in Selenium WebDriver?

Page Objects and PageFactory on Selenuim Wiki.

Page Object Design Pattern on Selenium official site.

There are other approaches, but these one are the most common for a long time.

vitaliis
  • 4,082
  • 5
  • 18
  • 40
0

everyone mentioned page object model, but if locators get changed frequently, that won't solve the problem. You'll still have to fo to each object and updage locators

I would be looking for a solution on application side. For example ask developers add unique attributes that are not a part of css, but can be used by automation. You can call them whatever you want, for example test-id and then you can even declare your own locator strategy in protractor and make your life simpler

If you need more info lookup protractor data hooks

Sergey Pleshakov
  • 7,964
  • 2
  • 17
  • 40
  • yup thats is what iam proposing too. I mentioned keeping a file with application asset which could have anything needed for automation, you are saying maintain those same as part of the html. – irlatech Feb 01 '21 at 18:17