Introduction
Page Object Model (or POM), is a design pattern in Selenium in which we create an object repository for storing and organizing the web elements and objects. It is a potent design pattern used in Web/Mobile automation across the globe to reduce code redundancy and test script maintenance.
Why do we need the POM approach?
Doing automation using the Selenium web driver is not a tough job, we just need to locate the exact web element using the different locators in Selenium.
From the above screenshot,
- We are Initializing the web driver
- Navigation to the web application
- Locating the dropdown web element using the locator
- Performing double click functionality using Action class
Since the script is small, maintenance is easy. But with time the suite will become more complex and more lines of code will be included hence the code maintenance will be difficult.
Let's discuss some challenges seen with such a practice.
- There is no separation between the initializing of the web driver and the navigation to web page classes, it will be difficult if we need to change the browser or the URL. The user needs to make these changes on every page.
- If we need to use the same web element on another page, we have to write the same code again and again. Hence the code will become non-reusable, leading to duplicate and unreadable code.
- Suppose the same locator is used in multiple class files, and if this locator gets changed at some point. It is a very tedious task to change or update this locator in all class files, especially if the project is large or complex, which will burn out time and energy.
What is a POM Model?
The POM model or Page Object Model is a design pattern or framework in which we will split the Test classes, page classes, and base classes into different packages. The basic idea of the POM model is like, different pages will be separated into different classes and the selectors for those classes can also be separated into different classes.
Advantages of POM Model
- POM enables the creation of a selectors repository within the project and from this repository, the user can easily make modifications and reuse.
- A Base class or a Common class can be used, and from here the user can initialize the driver and can store the reusable methods. For example, we can include the wait function into a method so that it can be called by simply one line of code whenever needed.
- The objects will not directly depend on test scripts. An object can be called by one or more test scripts, which helps us to create objects once and use them multiple times.
Sample Structure of POM
The below figure shows the sample structure of POM, in which we do have a Base package containing a common class in which the reusable methods are scripted. We do have a Page package and Selector package in which the actions to be performed are wrapped up in methods, and the selectors used for those pages are written under different classes from the Page selector package. And finally, we have the Test package in which different test classes are used to run the test scripts.
Conclusion
Building a test framework is always a cumbersome process, but once you build those frameworks the maintenance of the code will become easier. As we discussed, implementing such practices will reduce code redundancy and promote the reusability of the code hence the optimization. The setting up of a framework may vary from project to project and also will depend on the tester’s easiness, However, the basic concept behind the POM model will remain the same. As automation testers, we should be aware of such frameworks to make our coding practice smoother and easier.
Happy Learning!!