The Undocumented documentation of Page Object Pattern

If you are into automation testing using selenium, you may be knowing about the Page Object Pattern suggested by selenium forum available at url :
https://code.google.com/p/selenium/wiki/PageObjects

The documentation suggests the approach for implementing Page Object Pattern for automation and what are the advantages of it. In here I wont be writing about what the documentation suggests and talks about it. So lets directly jump onto the main subject and learn about what the documentation does not contain. Following are those points:

• Implementing a Page Object Pattern for a single page application
• Approach towards defining methods for functionality

Implementing Page Object Pattern for a single page application

With new web application development technologies coming into play on a daily basis web applications has reduced to very few pages and even sometimes to one page url. This becomes a challenge while implementing Page Object Pattern. The question arises is, how to segregate the pages as there are only few pages in the application but there are lot of functionalities to cover in them. If we go ahead with the conventional segregation methodologies we will have very few page classes but with lot of functional methods defined in them. We will fall into the same problem of code management that we were trying to solve using Page Object Pattern.

The solution to this is to enhance the Page Object Pattern guidelines. This includes segregating your page classes based on features, sub-features, functionality etc. and not by page urls. To explain this we have a perfect example of Gmail. Gmail is a single page but there are lot of functionalities available in the said page like navigation, hangouts, inbox, Search, compose and mail folders.
If we go with the conventional method we will be forced to define all the functionalities of compose, hangouts contacts chat, inbox etc in a single class. With the enhanced model we will define separate classes for each of the feature ex. ComposePage, HangoutPage, InboxPage, NavigationPage etc. By using the enhanced model we can fully utilize the advantages of using the Page Object Pattern.

Defining methods for Page functionality

The guideline suggests users to define functionalities as method inside page classes and it ends there. It does not talk much about the segregation,  approach or anything of such sort. Anyways lets cover it here. When planning to define methods for the functionality try to follow following added guidelines:

• Segregate your functionality into smaller functionally executed methods. Lets take an example of login use case where user enters username, password and click on submit button. While writing a functional method for login you should think of having methods like enter username, enter password and clicking on submit button. This way you will have more control on the code and you can provide more utilities to user who is writing automation tests.
• Think of functional as well as structural method declarations. Taking the above example. login method that accepts username and password arguments is a functional method whereas enter username, enter password and click on submit button methods are structural methods. As said in the first point structural methods makes code more readable and represents a flow of user actions. It also provide more power into the hands of end user who is using them for writing automation tests.
• Think of positive and negative scenarios of a functionality while defining methods. I will again take the example of the login functionality. A login can be successful or it can be failure. try to support both kind of scenarios in a single method. This can be achieved in two ways:
• Allow a Boolean value to be passed as argument to the method that will decide whether the scenario for which the method is being used in positive or negative.
• Another way is you written a Boolean or some other object as return type representing whether the method execution was success or a failure.
This way you are covering more ground in the functional methods and giving more power to the user writing automation tests to write different types of tests scenarios with the same given method.

The above suggestion helps in making tests more readable, manageable and in providing more functionality to the user who is automating. The initial time taken to write page class and page methods will be more but there will be very less time spent on writing automation test cases for the said functionality as the methods list will contain methods that supports all kind of related functionality from low level to high level as well as both positive and negative scenarios.

This is a cross post from my company blog here, where I had originally written it.