Best way to store locators

Question

I'm following page object design pattern for Selenium automation and I can guess that many people store locators in .properties file and access them in code. It seems great to keep locators at separate place.

Since, I haven't work on any big project for Selenium automation, I would like to know thoughts on following so that I can avoid problems that might raise in future:

1. Is storing locators in properties file helpful in big projects(where test cases are more than 1000 or so)?

   a) If not helpful in big projects, what are the difficulties that make us not to store locators in properties file?

   b) If it's helpful, what are the precautions if that are taken makes job easier?

2. Is storing locators in page class itself is best way in comparison with properties file?

Antilog

Answer 1

I would argue storing the files in the page class itself. Loading from properties file would incur additional overhead or parsing a large file. Maintaining such a file would also be harder, even with a good tool support you would be forced to use CTRL + F more than you should.

Even on a more conceptual level it feels wrong. A good fit for storing in properties files are configurable parameters, and especially the ones that are good candidates to be tweaked in runtime.

Locators don't have this nature. If the benefit you're seeking is declaring in a central place you should instead use dedicated constant class, which will give you much better refactoring options.

Eiser

Answer 2

I would definitely agree with @Master Slave. The main purpose of selenium is to make the UI testing easier. Storing locators in the property file is cumbersome and additional overhead plus a nightmare for refactoring. One of the main reasons why the PageObject is popular is because it's ability to map elements with a very intuitive way

@FindBy(name="q")
private WebElement searchField;

@FindBy(name="btnG")
private WebElement searchButton;

It's just not only more readable but also far easier in case of refactoring and debugging. And, when something goes wrong on the page or changes there is a KNOWN place you go to change and you know where it is!

Desiderata

Answer 3

There are two basic ways:

1) Using FindBy annotation

@FindBy(xpath = "//*[@class = 'stackoverflow']")
private WebElement question;

2) Using By / WebElement class in the method structure

By stackoverflow = By.xpath("//*[@class = 'stackoverflow']");
WebElement stackoverflowElement = getDriver().findElement(stackoverflow);

And I completely agree with @Saifur and @MasterSlave.

Dactylology

Answer 4

I agree for the small projects with one running environment. Lets assume we have the project runs on two environments like Test and Production. Assume that in Test the locators are changed, then if you want to change code that will work properly in the both cases you should go to the branch. In case if locators placed in the property file you just change the file belongs to the environment.

Tuinal

Answer 5

I am not against storing locators in any format - either properties,INI, XML or xls as long as each file is small and manageable. I think, as we are talking about 1000 test cases or more, for global variables [like URL, port number, username, password, email ] which are used only once, shall be stored in a separate global_variables file. Locators for EACH page can be stored in SEPARATE files. If one files is maintained for each page then locators are manageable. Pages will import ONLY file which is needed. Clearly this approach creates more number of properties files as number of pages. This can be bettered by creating single file for related module or feature pages. Anyways as user we need to balance between less but huge locator file or more but smaller manageable locator files.

Armanda

Answer 6

I am working on a similar strategy, where I need to decide which locator strategy is the best. What would be the best place to store the locators.

For code / property files, I have the following cons:

• Time consuming to change the value of a single locator
• Having stale locators/elements in the code
• Makes the code bulky
• Running tests on pre-prod and prod environment with different locators, results in creation of branches and duplication of code.

However, I am more inclined towards storing locators in a separate database and enabling its usage through a dashboard. I also feel this is very subjective to how your automation framework is setup. For a large scale framework, having over 1000 tests, having them separate makes more sense.

Loritalorn