I wanted to discuss the topic of use or not use the page-object pattern. Should people use or not use the page objects, what advantages they give and what are the disadvantages.
Close look a Page object Model
The page object is a design pattern for reuse and maintainability, which is a layer of indirection on top of a web page. It is a concept of group elements based on the contents of a page.
Page objects intend to make end-to-end tests readable and more comfortable to maintain. Instead of interactions with a page, a test controls the page using an instance that represents the page user interface.
According to the wiki
Code maintainability – There is a clean separation between test code and page specific code such as locators and layout, which becomes very easy to maintain. Code changes only on Page Object Classes when a UI change occurs. It enhances test maintenance and reduces code duplication.
Readability – Improves readability due to clean separation between test code and page specific code.
Code reusability – We could achieve code reusability by writing the code once and use it in different tests.
Prematurely designs UI elements for reuse violates the YAGNI principle (“You aren’t gonna need it”).
Tend to get huge and challenging to maintain. I saw page objects with more than 200 locators, yea 200! and also methods that consume all these locators so you can imagine a page object of 800 code lines.
Breaking the page objects into smaller ones still not solves the problem. If we have a dashboard page and each section of the dashboard has a complex logic split on mini page objects, the dashboardPage has to consume the other pages like the dasboadWidgetPage and so, what makes code more hard to read and maintain.
The documentation of page objects usually is not well enough to help write new tests.
Page objects introduce an additional state into the tests, which is separate from the application’s internal state. This makes understanding the tests and failures harder.
The proposed solution is to stop using Page Objects and use actions or intents. Instead of declaring a page object with all the methods and locators for the page, try to create specific actions and don't create locators outside the methods that will consume them.
This initial page object
Can be refactored to this
This little example shows a refactor that avoids declare locators that only will be used for a method making the LogIn more easy to read and maintain.
This new design looks interesting as an improvement for the page objects pattern that ends up with a lot of code that is only consumed in one place. I have to see how It works with large projects.