4

On the login page, the user name, password and login button fields all have id/class name in source code.

So when writing web driver script, if the code gets changed then does the web driver code also need to change?

Improve this question
1
  • 1
    Mostly developers do not change locators frequently. But still I prefer to use Xpath to locate elements. And yes If developer change locator then in selenium code ,you will have to change it otherwise selenium will throw no such element exception.
    – Helping Hands
    Aug 1, 2017 at 9:34

3 Answers 3

Reset to default
8

Your WebDriver code will always depend on the application code. That's why choosing good locators is so important.

My preference is (more or less in order)

  • Locate elements by ID - Unless the application generates dynamic IDs that are different each time the site is rendered, ID is the most stable and least likely to change.
  • Locate elements by name - Again, the name element is unlikely to change - possibly less likely to change than ID because form fields generally submit by name.
  • Locate by CSS class - Less reliable because each time the site is re-skinned, the CSS class names can change. Additionally class name is not going to be unique.
  • Locate with XPath - The reliability of XPath depends on how the XPath expression is constructed. The more it depends on the HTML DOM, the more fragile it is. I prefer to avoid this if at all possible.

I also prefer to structure my code to minimize repetition, by using patterns like the Page Object pattern. The goal here is that each field locator exists in exactly one place in my test code. That way when the code changes in a way that forces my test code to change, I only need to edit my locators in one unit.

Improve this answer
5
  • 1
    Other way to avoid back-and-forth code fixing due application changing is to use the Automation suite in the CI pipeline. As soon as a developer checks in a merge request, the CI will break the test and he will go there and fix it in no time, because he knows why and how he changed that area of the application. Automation is to provide fast feedback, catching bugs is a secondary goal.
    – João Farias
    Aug 1, 2017 at 13:49
  • @JoãoGFarias: Yes but: your approach requires developers to understand webdriver, pageobject, and locators. And care. You are lucky if you work for organization where all that is true, but many of us are not as lucky. I am not saying it is good way to run the business - i am just saying that reality is sub-optimal on many organizations.
    – Peter M. - stands for Monica
    Aug 1, 2017 at 14:05
  • 2
    Any front-end developer should be quite familiar with locators and pageobjects since that's how CSS is applied. From there, you don't really need to understand webdriver to understand how it locates elements and how being unable to locate elements prevents the test automation engineer from doing their job. My personal experience is that a little friendliness towards the front-end developer(s) will easily get you the locator support you need.
    – Cronax
    Aug 1, 2017 at 14:31
  • 1
    I would probably include css selectors above XPath. I didn't like them at first, but as I've used them more I've found them easier to read and cleaner. They also have a slight performance benefit, but that's not very significant. XPath's are a bit more flexible with text() and traversing the dom if necessary.
    – mrfreester
    Aug 1, 2017 at 15:53
  • Agreed about css selectors >>> XPath. Peter Masiar, assuming the tests are reliable and fast enough, I think any manager or developer would be on about using Automation as a merge-blocking tool - No one wants to introduce bugs (specially functional ones). Most people already block merges when unit tests failed. These are easier to be reliable and fast - the big work (whole team work) is to build the Automation suite with these characteristics.
    – João Farias
    Aug 3, 2017 at 15:49
2

It depends on what changes has been made on the page.

For example suppose you have 10 element in login page and developer changed id, attribute value or other thing of 2-3 elements. In this case it will throw NoSuchElementException for changed field So you have to again locate those element and update the locator in your script Suitable option for this case

  1. Property file for all locator
  2. PageFactory

But in case some functional change done in your site then you have to again validate your complete test script as per changed flow or functionality.

Improve this answer
1
  • I think comment is on wrong place :)
    – NarendraR
    Nov 7, 2017 at 10:40
1

Your test automation code directly depends on the application code under test.

Track markup changes

  • establish communication between developers and testers - make sure your test automation team knows when there is a relevant change in the application code
  • developers themselves may participate in writing or supporting automated tests - this may be especially useful when markup is changed - an author of the change may fix affected selenium locators as well
  • run your tests regularly on schedule on a CI server

Choose element locators wisely

It is important to be smart about choosing a way to locate elements on a page - some locators have a higher probability of being affected by a layout/design change, some are more or less fragile.

At the same time, your locator should be readable and unique. There is a pretty long discussion with multiple great points on the subject here:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.