Use Page Object vs other models for Automation in Selenium Webdriver? [duplicate]

Question

I have been doing automation testing since last 2 years and I am following below ways for any website and mobile application automation testing.

1. Create Global Method class where I implement all test cases
2. Create class for constant values where I put all constant values
3. Create Utility package and Add class under it to invoke browser and webdriver
4. I do data driven and all within global method class.

Above is easy for me and also easy to maintain as well. But When I look at Page Object Model , I got confuse because many people are saying page model object is easy to manage but how? It require to create methods for each field and becomes long time taking when we have form with 100+ fields.

I have checked page object model example here.

Please help me that how can I decide that which model I should use for automation. I know it is depends in project and requirements but still I need some good hints. And Suggest other models also if suitable.

Answer 1

Generally architecture of System Tests should comprise Page Objects, Business Layer and Test Cases. The fact that your Page Object gets bigger with the number of the fields makes sense. It will happen. The complexity of Page Objects gets higher with the complexity of UI. All in all you need to keep a mapping to the page somewhere. Even if you find a way to get it out from Page Objects, it will still exist in a different place. So you can't do anything about that.

What you can do is to ensure that the selectors of your page elements are easy to maintain - there are IDs, Names, custom attributes in HTML helping to find an element. Then you'll find that your Page Object isn't that complicated anymore. This is so crucial for the maintenance that you need to ensure everyone on the team understands that and is okay with adding anchoring info into the HTML.

Another problem that may arise with Page Object is what to do if elements repeat on multiple pages. The solutions include:

• Nesting Page Objects. E.g. having UserInfoBlock in QuestionPage and UserListPage
• Just accessing UserInfoBlock from your Test Cases (or better - Business Layer).

Check out this article to find more info on how the layered architecture of the tests should look.

Answer 2

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 3

Depending on your coding style and programming language, page object can be very simple. My page objects have only one method to fill form values (or more than one only if input is very complicated, but still just few). And these methods all use universal fill() form, which accepts (optionally ordered) dictionary of locators and values to be filled. And this universal fill() method lives in base class anyway.

I love Python because it allows for such very compact code, and very flexible creating of data structures (data literals) and powerful one-liners like list comprehension.