Page Object Model — An introduction
One of the most popular automation test design patterns is page object model (POM). POM has become increasingly popular between QA automation experts due to numerous reasons. Some of them are:
- It contributes at decreasing the degree of code duplication.
- Facilitates a better maintenance of test data, locators and test instructions.
- Enables better change management in code.
Other advantages consist in the fact that:
- Implementation of the test data, objects and methods are separated from each other, increasing the readability of the code.
- Test scripts classes are developed and maintained separately than the page classes, and the page elements can be accessed from different test scripts.
- The WebDriver and all the objects are created once, reducing the consumption of computer memory.
In this tutorial, we’re going to explore how to apply the concepts of POM in your project using Java and Selenium framework. We’ll be using a simple script, just to show the principles of POM in action.
The test script consists of the following actions:
- Access Wikipedia website.
- Login using my credentials.
- Search for Document Object Model.
First, let’s delve into the structure of the project:
We can see that there are five packages in total, one for each page and one general default package that contains the test script.
Let’s start with utilities package! Here we define WebDriver object and two methods: one for instantiating this object, and one for closing it.
The first method is also accessing the webpage that we will use in our test script.
You can choose to make your methods static so that you will be able to call them without instantiating their corresponding class.
Second class is the one that hosts the implementation details for the welcome page.
Here I define the code of the button for English language. You can see that we restrict access to the button through encapsulation, and we provide a public method for accessing it. The element is also final, so that it won’t be modified later on by some other methods, if we decide to include this button in other testing scripts.
Important to mention is the fact that you must adhere to Java code style principles. POM won’t be easy to understand if different styles are used within the project.
You can see that in the above example, the final element is written using capital letters, the fields are substantives, and the methods are verbs. This way, your code will be easier to understand, and can be digested even by people that don’t have programming experience. To get some understanding about styles and conventions, I recommend this book.
Next is the login_page class, where I define the details on how to login into Wikipedia using my credentials.
This class contains the web elements used for login and the methods for accessing them. The same principles are used: elements are private and constant, whilst the methods are public and static so that they can be accessed without instantiating the class.
The password is retrieved from a file that is created at the root level of the project, as you can see below:
For demo purposes, I just typed my password into that file, but you should opt for a more secure approach, like encrypting the password in the file and decode it using an encryption library.
Finally, the main page, where we search for Document Object Model and we open the most relevant page.
Same principles, objects are made private, static, final and methods are public for accessing the elements. You can choose to create a class in which you implement the strings required throughout the test script, or you can specify them in the script itself. I’ve chosen the latter, since we only have a single search string, but the first option allows you to hide even more of the implementation details, and specify only the actions in the test script class.
And at last, the test script class:
Fairly simple to understand, and even non-automation QA’s can run and create tests using this pattern. Here I use only the methods that were defined in each class. This is why you need descriptive method names, so that everyone will know what actions the script will follow by only reading the methods’ names.
As you can see, the test script doesn’t need to change in POM, whenever a change in the code of your web application is made. You only need to change the code that is inside each page class, and this makes your testing code base more manageable.
That’s it folks! Thank you for choosing this mini-tutorial to find more about POM. To have a closer look to the code that I presented, you can fork this repository.