Reputation: 14046
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:
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?
Upvotes: 5
Views: 7755
Reputation: 188
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:
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.
Upvotes: 0
Reputation: 16201
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!
Upvotes: 5
Reputation: 352
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.
Upvotes: 1
Reputation: 1895
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.
Upvotes: 1
Reputation: 909
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.
Upvotes: 1
Reputation: 28529
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.
Upvotes: 9