Page Object Design Pattern

One of the most widely used and efficient ways to automate an application, be it web, windows, mobile or any other, is following the approach of Page Object design pattern.

A Page Object design ensures that  there is class or a separate module for each page/form which encapsulates all functionalities of that page/form.  This reduces to a great extend scope or need of code repetition of any type.

In this kind of a design, a class A of a page/form A will make sure all the objects present in that page A are defined in this class, all the properties to be accessed from this page are defined in class A and all the actions to be performed in the page , example entering data, clicking on submit, verifying a field etc. are encapsulated only in the class A in the form of methods. Whenever any action needs to be performed on this page or a property needs to be accessed from this page, an object of class A has to be created.

Let's take an example. An application has two screens :

Screen 1 contains :

'UserName' field

'Password' field

'Submit' button

On entering username and password and clicking on submit in Screen 1, the user is navigated to Screen 2.

A page object class for Screen1 would look like :

This is an example of how a simple page object class could normally look like.

Few points to remember about Page object model:

- the actions which expect the navigation to go to another screen return a type of page object class of the other screen. In the example, ClickonSubmit expects to open Screen2 , hence return type is an object of Screen2 class.

- the actions which expect no navigation, but to stay on the same screen, return a type of the same class. In the example, Enterdata expects no change in screen, hence return type is an Screen1 object.

- all actions performed in a page are limited and encapsulated to a single class.

This is just one approach, great and efficient, to follow during automation although not a mandate. Deciding on what kind of a framework to develop, which tool to use, what design patterns to follow also depend on the kind of application being automated and what is required and expected from the automation of it.