During test automation, one of the practices that helped me the most to maintain code organization and reusability was the evolution of the Page Object Model (POM). Initially, the POM is already an excellent way to abstract the structure of the page and its elements, but we can go further. Recently, I have been applying a technique that consists of transforming the components of a page into separate classes, creating what I call the Components Page Object Model (CPOM).
I would like to remind you that this article is a possible direct continuation of Automating Tests with Playwright and PageObject: A Practical Approach | by Rodrigo Cabral. It would be interesting to have a basic knowledge of Playwright and PageObject (POM) for a deeper understanding of what will be explained here. Therefore, I recommend reading the first article.
What is Component Page Object Model?
The Components Page Object Model (CPOM), is considered, in my humble opinion, an evolution in the way we work with POM. In *CPOM * we must create one more layer in our automation, the layer called Components, in it we will create classes referring to each component belonging to our system, which are independent of the page where the test is being developed.
Imagine that we have more than one page with common elements, such as TextBox, table, buttons, etc. In the POM, we would have to create interaction functions with these elements in each page, generating code duplication and some rework. The CPOM was developed to solve this problem, allowing the creation of specific classes for these elements (components), concentrating the corresponding actions in them.
We can see an example, we will do an example of a button:
In this model, the Page class is responsible only for the test logic, while all actions are performed in the “Component” class. We can see an example in the following code:
Pros and cons:
Pros:
- Enhanced Reusability: Components like “table” or a “button” are often reused on various pages. With CPOM, you create the component once and reuse it across different Pages, avoiding code duplication.
- Superior Organization: The separation of responsibilities makes the code easier to understand and maintain. Each Component Page Object class has a specific focus, making reading and debugging simpler.
- More Modular Tests: By isolating components, you can test them independently, ensuring that each works correctly before integrating them into the main page.
- Scalability: As the application grows, CPOM makes it easier to add new components and modify existing ones without affecting the rest of the code.
Cons:
-
Initial Complexity: The initial implementation can be a bit more complex than traditional POM, as it requires creating several classes.
-
Unnecessary Overhead: On very simple pages, creating Component Page Objects may be unnecessary and add complexity without significant benefits.
Conclusion
I believe that the Component Page Object Model (CPOM) is a natural evolution of the Page Object Model (POM), bringing significant benefits in terms of reusability, organization, and scalability. It is a technique that has helped me build more robust and maintainable test suites. However, by adding one more level of abstraction, it can increase development overhead, resulting in unnecessary complexity in smaller systems. For large systems and scalable testing, CPOM is highly recommended.
Remember, as I once said:
„Creating code, like making good food, may take time at first, but it will be rewarding when served.” — Cabral, Rodrigo (Tradução propria)
Sources and Useful Links
Fast and reliable end-to-end testing for modern web apps | Playwright
Article to help you install docker with playwright:Docker for QAs: Standardizing Your Tests with Playwright | by Rodrigo Cabral
My portfolio in English: https://www.rodrigocabralqa.site/en
LinkedIn: Rodrigo Cabral | LinkedIn
GitHub: RodrigoOBC (Rodrigo de Brito de Oliveira Cabral) · GitHub
