2

I have QA, Staging and Production environments. Out of these QA environment is changing(new build) almost daily (if its not the case with everyone lets just imagine it, for sake of the problem).

Every time a new build comes the locators (XPath, ID, Name, CSS, Class etc.) changes and fail the Automation testcases. I want to prepare my Automation testcases in way that it won't fail even when locators changes i.e. when new build comes.

My answer is prepare one properties file for each environment i.e. QA.properties, Staging.properties and Production.properties. Each property file has object repositories. Find and write new locators everytime there is change. But that would be a time consuming task, finding and then writing new locators everyday.

Is their any optimal way of doing it.

Improve this question
4
  • We too have daily test builds for QA environment, but in your case why ID and Name are changing for all the locators every time? This should not happen, any specific reason for that?
    – Dhiman
    Oct 1, 2015 at 13:07
  • I agree - Could make it clear to the dev team that there is a time and cost hit each time these change and maybe that can change something on their side to reduce the changes?
    – Brian Folan
    Oct 1, 2015 at 13:18
  • Me too never encountered such situation. But framework need to be designed, is to be designed in a way that such scenarios handled. Its was a question from client and we need to show assure him that its handled well.
    – paul
    Oct 1, 2015 at 14:55
  • why not add unique id's so the app is testable?
    – Corey Goldberg
    Sep 12, 2018 at 4:17

2 Answers 2

Reset to default
2

Get your developers involved. It sounds as if you already know how to write locators that are less susceptible to change. Those techniques still require that certain properties of the page stay the same. If IDs, names, CSS properties, and so on are constantly changing, you may need to talk to your developers about what you are trying to accomplish and how their HTML changes impact you.

If your pages change constantly, it may not make sense to use automation. Automation makes the most sense when the implementation changes but the interface stays the same. If your pages change so much that you can't write reliable locators, ask yourself whether you would be better off testing by hand. Or whether you should only automate the pages that don't change as much.

Improve this answer
1

Are you avoiding full/absolute xpaths? How much does the text the user sees change in relation to xpaths? If for example you want to click a save button, rather than using

/html/body/div[4]/div/div/div/table/tr[2]/td[2]/button

I would use:

//button[normalize-space(.)='Save']

If I want to enter some text into a two column table (labels on the left, inputs on the right) rather than use something like:

/html/body/div[4]/div/div/div/table/tr[2]/td[2]/input

I would go with:

//td[normalize-space(.)='First Name']/../following-sibling::*/td/input

I go a bit further in extracting these xpaths to utility methods where I am passing in the text bit. So for example:

void typeIntoLabeledInput(String label, String text) {
    driver.findElement(By.xpath("//td[normalize-space(.)='" + label +
        "']/../following-sibling::*/td/input")).sendKeys(text);
}

These xpaths will run a bit slower than absolute xpaths it's a bit of a trade off between your time keeping them up to date and the time it takes the tests to run.

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.