Best Design Pattern for Selenium Automation for Large Scale Application - selenium

Question

I would like to know the best design pattern for Selenium for automating large scale SaaS Product.
Looking for all your comments on this.
and for large scale application i preferred keeping my xpath's for web elements in page object file. but my lead wants me to keep xpath's in Properties file and we should access Properties file for every xpath's. Is this a good approach of keeping xpath's in properties file for Large Scale SaaS application?

Answer 1

Your leed wants you to implement Object Repository Pattern.
I think this idea is as old as HP QTP (QuickTest Professional) where it is extensively used - but I may be wrong, it's only my opinion.
In short (a quote from the above link):
Object Repository is a centralized location where we can store objects
information, it acts as interface between Test script and application
in order to identify the objects during the execution.
We always recommend using external file for object repository rather than hard coding the objects and its properties
directly into our code. If you are asking me why this is? Reason is as
it reduces the maintenance effort and provides positive ROI, for
example say any of the object properties change within our application
under test, we can easily change it in external object repository
file, rather than searching and doing updates for that object
individually in the code
Think of a scenario where you have a Webpage and it has multiple
sections, multiple frames and hundreds of WebElements. Obviously you
do not want that once you type the page name and it will give you all
the elements available on the webpage. If there are few elements, it
is fine to have the same structure but if there are many then it is
advisable to divide your page in to different sections for e.g.
header, footer, left navigation, center content and right navigation.
Then categories each WebElement under their parent element.
I think this pattern does not stand in contradiction to the Page Object Pattern, they can both work very well together. It brings greater transparency to the project and forces developers/testers to maintain better readability of the project, which helps in maintaining it in the future.
But the above is only a bit of theory, one may ask how this pattern can help in real life?
Consider a simple example. Let say that there is a piece of code:
public class SomePageObject{
.....
.....
public void doSomething(String value){
findElement( By.xpath("//*[ #class='left-content']//button[ contains( ., 'list-selector' )]") ).click();
wait.until( ExpectedConditions.visibilityOfElementLocated( By.xpath( String.format( "//li[ *[ text() = '%s' ]]", value ))).click();
}
I have seen code like this hundred of times. What do you think about this code ? Yes, it follows the well known Page Object Pattern. But it is horrible.
Looking at this code, can you guess what is it doing? Definitelly No.
What error message will you get in the log when this code will break due to change in UI of second element ? Most likely something like this:
org.openqa.selenium.TimeoutException: Timed out after 30 seconds
waiting for visibility of element located by By.selector: //li[ *[ text() = 'New York' ]]
Can you guess, looking only at this error message, which part of the application it concerns and where it can be found in the code ? No.
An automation engineer can find it in code looking at stack trace but a junior tester who doesn't know java, selenium etc. cannot fix it looking only on the error and a printscreen (if available).
In many cases in order to fix the error, the automation engineer needs to run this test case on a local machine to replicate the issue.
How can it look like using Object Repository Pattern ?
There can be a property file which may look like this:
....
orderPage.citySelectButton=//*[ #class='left-content']//button[ contains( ., 'list-selector' )]
orderPage.citySelectListElement=//li[ *[ text() = '%s' ]]
...
...
and a code which may look like this:
public class SomePageObject{
.....
.....
public void doSomething(String value){
objRepoFacade( "orderPage.citySelectButton" ).click();
objRepoFacade( "orderPage.citySelectListElement", value ).wait().click();
...
)
}
The error message in the log may look like this:
RuntimeException: time out waiting for element: orderPage.citySelectListElement
located by By.selector: //li[ *[ text() = 'New York' ]]
And now even the junior tester, looking only on this error message, is able to easily guess in which part of the application the error occurred, and which exactly element is broken. The tester may be trained how to inspect an element on the page using the developer console (F12), correct the selector in the procerties file, and fix the issue on his own without the help of automation engineer and without touching the code at all.
Preasumbly from your leed's point of view the latter (Object repository) is a better solution because it can employ more junior testers and fewer automation engineers and reduce costs.