Single Responsibility Principle in Test Automation
If you have used selenium for your browser automation, there is a chance that you would have used Page Object Model to write a maintainable test suite. The page object model suggests that you treat each web page as a real world object. The Page Object class contains the web elements present in the page as attributes and methods representing page behavior are created in the class in order to interact with the elements on the page.
Lets take an example to understand Page Object Model. Consider the AUT (application under test) has a login page before user can navigate to the home page. The login page has three components — email id textbox, password textbox and login button. And if we have to apply POM, we will create a class say, Login, and it will define three webelements — email id textbox, password textbox, and login button. We will create a method loginToApp that accepts two parameters — email id and password and then enters email and password and clicks login button.
So Page Object Model demonstrates one of the important principles of software design — Single Responsibility Principle. SRP is defined in Wikipedia as “The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program’s functionality, which it should encapsulate. All of that module, class or function’s services should be narrowly aligned with that responsibility.”
That means a class should have only one responsibility and therefore only one reason to change. This reduces the risk of affecting other unrelated functionalities when a change made to a class.
The POM, at first glance, seems to be a fitting demonstration of implementation of SRP. The page class encapsulates the attributes and behavior of the page. Whenever any attribute or behavior changes, we can safely update those in the page class without having to change anywhere else.
But this may not be entirely effective if we treat the complete webpage for the Page Object. Lets see why it is so. One of the guiding objective of SRP is to write small classes so that any behavior change can be isolated to a smaller portion of the code base. However a POM implementation as described earlier may lead to huge classes if the page has lot of components. Consider the following page on the popular website https://www.phptravels.net/home.
It has a header component containing option to choose the currency, language and my account. It also has a menu with HOME & COMPANY and then it has a component containing search criteria selection options. If we make one page object class for the home page, that class need to contain quite a few elements. This makes it a God class. Also the header and menu are present in other pages so the elements inside that need to be defined in each of those page object classes. Lets see how it would look like if we encompass all the elements in one class.
Now consider a situation that we need to choose an option from the drop down with value COMPANY. We would generally write a step to ensure that the page is loaded and then chose the option. If we have single page class for the page, then we would probably choose the component which takes longer to load so that we are assured of page loading, say SEARCH button. So the test will always have to wait for the SEARCH button to load until it can perform any action on any of the component on this page. And this is not really efficient. Because the component we want to interact may have been loaded before.
So how can we apply SRP to make the POM more manageable?
Lets treat the Home page as a composition of components such as — header, menu and search criteria and create 4 POM classes
- Header — containing currency selection, language selection and My Account option
- Menu — containing HOME, COMPANY option
- Search — containing the elements in the middle to search for hotels. Here it can be further broken down to have classes for each of the options e.g. HOTELS, FLIGHTS, BOATS etc. however we will ignore that for the sake of the scope of our discussion
- Home — containing the above 3 components
Now our classes look smaller, better and manageable. If there is a new element introduced in any of the component, the change can be isolated only to that component and the Home page class does not have to be concerned about it.
This is how we can leverage Single Responsibility Principle to write better code. In the next article we will learn how we can achieve abstraction using factory pattern.