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?

Kate Paulk
  • 31,513
  • 8
  • 54
  • 108
Nilam Nikam
  • 123
  • 2
  • 8
  • 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 01 '17 at 09:34

3 Answers3

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.

Kate Paulk
  • 31,513
  • 8
  • 54
  • 108
  • 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 01 '17 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 01 '17 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 01 '17 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 01 '17 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 03 '17 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.

NarendraR
  • 1,573
  • 1
  • 16
  • 34
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:

Community
  • 1
alecxe
  • 11,425
  • 10
  • 49
  • 107