How we scale our automation project Atlas using design patterns
By: Leyla Hasanzade
Tags: Selenium, QA, Testing, Automation, Design Patterns

Page Object Model

We will not go into description details of this pattern, we all used or read about it at least once on the world wide web. Briefly, Page Object Model (POM) is an object design pattern in Selenium, where web pages are represented as classes, and the various elements on the page are defined as variables on the class. All possible user interactions can then be implemented as methods on the class.

Let’s check the main points for building a class according to the POM using the Login Page of our application as an example.

Login Page

To reflect this page, we create a single class in our automation project. It’s best to make sure the class’s name is representative of the application’s page so that other contributors can easily locate the class associated with a particular UI page. Any of the elements on the page that will be included in our tests should have properties in LoginPage. These properties are locators to the elements on the actual page. It lets us not to hardcode these locators in any place we use them, so we define them in one place, avoiding duplication.

So, in this case, we’d create a LoginPage class.

The class should also provide methods that allow a test to interact with the application, such as setting input fields and clicking buttons, in addition to the properties. Here are some pointers on how to build these methods so that our tests can make the best use of them:

We write only methods/properties that are currently needed. If a new test needs a new method/property, we can always add more. We don’t have to manage any unused code as a result of this.

Transitions should return new objects. Methods return a handle to the class representing the UI page we’ve moved to when your click results in a page change. If, for example, clicking the log-in button takes us to the application’s home page, method returns a handle to the class that represents that page.

Methods in classes are neutral, in other words methods are generic enough to be used by any test that wants to interact with the page. This simply means we don’t write assertions in page methods.

Issues we solved with POM:

Separation of technical details such as elements in the browser (elements which perform this or that functionality), removal them from the logic of tests to make test logic clean and transparent and store them in different pages.

Reuse of the code that is written in those pages. Many test scripts go through the same pages, then it would be quite logical if code is written once and is invoked every time it’s needed, what, accordingly, will greatly simplify writing tests.

Example code from test script

Loadable Components

The problem is that when a test moves from one page to another, it has no way of knowing whether the desired page has fully loaded. Obviously, usual sleep or not waiting at all aren’t viable options. Usually, test engineers create explicit wait in the page class’s constructor or in its ancestor and override if required. So, what are our options for resolving this issue?

In Atlas all pages extend PageBase and override its check method and these overridden check methods in every page’s constructor do control loading of all most important elements of this page.