Page Object Model or External property file for Selenium Object Repository

Question

I am a beginner in Selenium WebDriver (Java with TestNg). I'm trying to create a framework of my own.

My question here is what would be the better option to store my objects (basically all the webelements of my website under test), Page Object Model or External Property file? Why? Is there a better method than those? Please help.

• user14572: @Peter Masiar : Thanks for your reply. As I mentioned in my post, i am a beginner and I am looking for a Selenium Automation role in a project where i work. They want me to be ready with the experience of working in a framework and I've got a month's time in hand. Hence this situation! Hope you understand :-)

Answer 1

In my framework, I do not write code for any of the the webelements. I just store the locators (it is in Python, so simple dictionary literal works pretty well) in pageobject file for the page. I generate webelement from that as I need them - this saves lots of code. I could pretend I use factory pattern, but I don't - it is all much simpler than that, because Python's dynamic typing ignores type nazis and makes difficult things simple.

My advice would be not to start with framework. Start with coding what you need, and refactor as you learn more what your code need. Unless you are really experienced Java hacker with lots of OO design experience - and if you were, you would not be asking this question here, I guess? :-)

Answer 2

Use Page Object Model. It follows encapsulation concept. In POM you develop web elements as private members, you will have parameterized constructor and member functions. Actual initialization of web elements happens inside member functions so no elements will be loaded into the stack at the time of constructor creation there by increasing the processing speed.

Answer 3

Given that your are using Java I would go with page object methods. For the way they are used, either approach will work.
For example I have converted tests and in one form I was using variables:

storedVars["css_phone"] = "css=input[name='auto_policy[phone]']";
storedVars["css_email"] = "css=input[name='auto_policy[email]']";
storedVars["css_street"] = "css=input[name='auto_policy[street]']";

and in the other approach these became (ruby) page object methods:

def css_phone
 "input[name='auto_policy[phone]']"
end 
def css_email
 "input[name='auto_policy[email]']"
end 
def css_street_address
 "input[name='auto_policy[street_address]']"
end 

but their use was essentially the same.

The important thing to focus on was creating good unique selectors that would not be brittle.

Page Objects are great in the right circumstances. They allow growth.

Initially when you only have a few fields on one page, they are not of much use. Each field is probably fairly unique already and identifying them is trivial and short.

As the application grows the following starts to happen:

• the same field is in multiple spots on the same page
• the same field or collection of fields are on different pages, e.g. many 'help' or 'login' buttons.
• the number of fields grows and different approaches by developers leads to style clashes.
• the correct way to identify elements become a longer string of finders cluttering up the test
• names of fields and containers change over time, sometimes consistently, other times not
• more business logic is added.

In these circumstances having the selector finders embedded in the test code leads to brittle, duplicate, error-prone, hard to maintain code.

Centralizing them in one place addresses these issues and helps:

• reduce duplication
• clarify readability of actual tests
• separate business logic from selector identification
• help reduce change and churn due to layout and styling changes
• encourages the same approach as all the selectors are in one spot

For example if selectors appear on multiple pages, page objects will help guide you to one identifier, such as id, that will be usable. You'll be forced to think about good naming and name spacing up front.

Answer 4

Instead, combine both. I have developed a support package that uses page factory to read locators from JSON.

Here is the article.

https://medium.com/@hemanthsridhar92/custom-selenium-page-factory-to-read-locators-from-json-48710f77e272

Let me know if you have any questions.

Answer 5

Using Page Object Model to design your automation test and Pyyaml to read the input/data with yaml format. It's human readable format.