Page Objects Model is best suited for applications which have multiple pages or states. Each of which have fields which can be uniquely referenced with respect to the page.
Advantages:
- Object Repository: You can create an Object Repository of the fields segmented page-wise. This as a result provides a Page Repository of the application as well. Each page will be defined as a java class. All the fields in the page will be defined in an interface as members. The class will then implement the interface.
- Functional Encapsulation: All possible functionality or operations that can be performed on a page can be defined and contained within the same class created for each page. This allows for clear definition and scope of each page’s functionality.
- Low maintenance: Any User Interface changes can swiftly be implemented into the interface as well as class.
- Programmer Friendly: Robust and more readable. The Object-oriented approach makes the framework programmer friendly.
- Low Redundancy: Helps reduce duplication of code. If the architecture is correctly and sufficiently defined, the POM gets more done in less code.
- Efficient & Scalable: Faster than other keyword-driven/data-driven approaches where Excel sheets are to be read/written.
Disadvantages
- High Setup Time & Effort: Initial effort investment in development of Automation Framework is high. This is the biggest weight of POM in case of web applications with hundreds/thousands of pages. It is highly suggested that if this model is decided to be implemented, then it should be done parallel to development of the application. Refer V-Model for Software Development Life Cycle.
- Skilled labor: Testers not technically sound or aware of programming best practices are a nightmare in this case. Perhaps this is the biggest mistake to make, employing unskilled labor in hopes of training them during implementation. Unskilled testers need to undergo a Training Boot Camp to be ready for such an undertaking. Also the Architecture of the framework should be defined clearly and completely before development in order to avoid any loopholes in later stages. Every application is different and it may require the automation framework to be significantly tailored towards it.
- Specific: Not a generic model. Automation Framework developed using POM approach is specific to the application. Unlike keyword-driven/data-driven frameworks, it is not a generic framework.
Irrespective of the disadvantages, POM is perhaps the most efficient and highly recommended approach towards any web application. As the framework matures it is perhaps easier to modify it into a hybrid framework from a POM approach than from other keyword/data driven approaches
Courtesy Stackoverflow Thread
Framework of page object Model
- Libraries : – Here all the jar files required like selenium , junit, testNG , msql-connector etc are kept.
- Resources :- All the properties files are Kept Here .
- Drivers :- As we know we selenium can be implemented on different browsers, we will need to locate different browsers drivers like chromedriver etc. In this driver directory all those drives are kept.
- Pages & utilities :-
- Utilities :- The frequently used code or functions/classes are defined here.
- Pages :- the different web pages having different WebElements are defined here, wherein the Different WebElements are defined using annotation @FindBy, and the operations like click or sending values if any are defined in fuctions. And those are used in the respective tests by creating object of that particular page.
5. Tests :- All the page wise tests are defined here, also the types of testings are segregated properly.
To know this more practically below is the link to sample project , where in Page object Model is implemented. I have used the project Invoice Plane which is open source for testing. You can download it from their site host it on your machine and use the below testing framework.