How to create Selenium object repository using properties file in Selenium
The concept of Object repository in test automation is driven by intent of storing the locators of webElemnt at a separate place. Here we will learn how to create Selenium Object Repository by using Properties file in Selenium.
As explained earlier, Test automation frameworks based on Page object model design pattern requires the tests to be kept separate from actual steps with the help of Page classes. Page classes contain WebElements(or locators) and methods to perform actions on them.
There are many ways to handle these two in a page class. The idea is to keep the locators grouped together and away from the test step methods.
Now someone in the test automation history, took this way too seriously and went too far. They kept the locators entirely in a separate file from the page classes. Page classes load them at run time to read the locators to perform any step on any webelement.
In this article we will see, how to store locators using properties file in Selenium Page Object Model.
Example Test Scenario
In order to understand this concept, we have taken a simple scenario which is scripted in the class GoogleSearchPageProperties.java .
- Enter a keyword on google search page.
- Press key ENTER
Sample Page Class To Store Locators In A Properties File
A page class is written for each of the application page which has some webelements. Every page class has a supporting .properties file. Locators are written as a pair of String name and value pair in a .properties file.
For Example: In the file GoogleSearchPage.properties, xpath locator of webelement searchBox is stored like below.
Now this file is loaded in the page class through constructor.
Please notice the constructor of the below class. Once the properties file is loaded, locators are read through below command.
These all strategies have been used by the QA community since very long and it is hard to tell which way is the best way. In software development, you will hardly come across a “one size fits all” kind of solution.
Advantages & Disadvantages
Every design principle has it’s own benefits and limitations. This is true even for all the strategies of Page object model too.
- When you store your locators in a separate file, it becomes very easy to maintain and the page class becomes uncluttered. As the number of test scripts increase, this increases size of page class too and then this becomes very helpfull.
- When the test suite becomes large, old and application evolves, some webelements will become obsolete and will be removed form the methods. By using this method, you will find it very tough to identify a locator which is declared but not used in the script.
Checkout the code repo
more code ?