The Page Object Model is a popular design pattern that provides a structured approach to organizing and interacting with web pages in automated tests, promoting code reusability, maintainability, and readability. How this design pattern is implemented can very from org to org.

Often I come across Cypress frameworks that use classes, modules, namespaces, or a combo of each of these. When it comes to Cypress automation and Page Object Model (POM) I think its important to highlight the advantages of using one or the other and see if that aligns with the desired design.

Please keep this in mind

Page objects primarily encapsulate the elements, actions, and behaviors of the page under test, while the test case itself controls the flow, data management, and assertions.

Example:

Classes: Classes provide a powerful mechanism for encapsulating data and behavior.

POM: Page Objects are supposed to be stateless and not manipulate data.

Therefore, I argue while yes you can use Classes in Page Objects, doing so is not the best option.

In the context of the Page Object Model (POM), where page objects are typically designed to be stateless or not responsible for managing changing data, the primary benefit of classes—encapsulation of data—may not be fully utilized.

In such scenarios, where the focus is more on encapsulating behavior and providing a clean interface for interacting with the page elements, an alternative approach without using classes could indeed be considered. Instead of using classes, you could utilize other modularization techniques such as JavaScript modules or namespaces to organize the page objects. Using JavaScript modules or namespaces can still provide benefits like encapsulation, code organization, and preventing naming conflicts. They can help group related functions and provide a logical organization of code entities, even without directly leveraging classes. In my experience, where i’ve built and contributed to Cypress automation frameworks that utilized both, I prefer using basic modules. This is serving as a reminder that when picking and choosing the design and architecture of a framework, the best option might not always be the “most common” or “industry standard” way. Most orgs I’ve worked tend to bring in this extra added layer of complexity into their automation frameworks that only overcomplicates things. I always look to clean this up when and where I can.