Introduction to Page Object Model Framework

Page Object Model Framework has now a days become very popular test automation framework in the industry and many companies are using it because of its easy test maintenance and reduces the duplication of code.

The main advantage of Page Object Model is that if the UI changes for any page, it don’t require us to change any tests, we just need to change only the code within the page objects (Only at one place). Many other tools which are using selenium, are following the page object model.

In the above screen shot, we have first identified the locators and defined it on the top after the class. In this way we can achieve readability of test scripts and we can easily identify locators and change them if needed at only one place.

Page Object model is writing all the functionalities / reusable components of a page that we want to automate in a separate class. Say now if we consider four pages as Home page, Login page, Create Account and Forgot password page etc.

As per Google Wiki Page Object"Within your web app’s UI there are areas that your tests interact with. A Page Object simply models these as objects within the test code. This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place."

For the above pages we will create classes as HomePage.class, LoginPage.class, CreateAccountPage.class and ForgotPasswordPage.class. In each class we will identify and write reusable methods which are specific to a page.

Here in The first page 'google home page' which will have many options like Search, Sign In, +You, Images, privacy etc links. based on the user action it navigates to respective page. Now all functionalities that we want to automate should have reusable methods/components for each page.

Now as our main page is google page we can navigate to other pages by clicking on any link from the google page. When ever we are navigating to other page, we need to return that page object. Else Return the current page object as this action doesn't navigate to a other page represented by another Page Object

The Page Object model provides the following advantages.

1. There is clean separation between test code and page specific code such as locators (or their use if you’re using a UI map) and layout.

2. There is single repository for the services or operations offered by the page rather than having these services scattered through out the tests.

In both cases this allows any modifications required due to UI changes to all be made in one place. Useful information on this technique can be found on numerous blogs as this ‘test design pattern’ is becoming widely used. We encourage the reader who wishes to know more to search the internet for blogs on this subject. Many have written on this design pattern and can provide useful tips beyond the scope of this user guide. To get you started, though, we’ll illustrate page objects with a simple example.

If you observe the above test, there is no separation of test and test locators. If this is the case, in future if the UI changes, it must be changed in multiple places. It will also become difficult to identify where these locators are used as the chances of locators are being used in multiple tests are more.

We will try to rewrite the above example by implementing the page object model:

In the above test, we have not used any locators. It is completely separated by driver.findElement 's, waits, exceptions and no static values in the code etc.We will be working only with the methods which are defined in multiple pages. Based on test, we will navigate to the required page and access those page methods.

Comments

This is so easy to understand. Thanks for this.
Could you also show how to use Actions class in any class of POM. My requirement is to move mouse over an element on Home Page after that it shows a set of elements in the dropdown list. I should click on any of the element from the list.

Another neat trick with the POM is to override the findElement method with your own copy that implements an implicit wait. This allows you to pass a time out value, if the element isn't added to the dom you get a webdriver timeout exception with lots of detail in your test failure. The implicit wait also means you can make your tests handle dynamic content rendering slowly on the page.