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.

  • 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 '15 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 '15 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 '15 at 14:55
  • why not add unique id's so the app is testable? – Corey Goldberg Sep 12 '18 at 4:17
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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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