12 November 2020

Automated UI tests with Selenium

Writing automated UI tests is not an easy task. Writing maintainable and reliable tests is even harder. Everyone who faced this challenge knows that. In this article, we’ll take a quick dive into one of the industry’s best practices that can help achieve this by using the Page object model design pattern.

Page Object Model pattern

Page Object Model is the most widely used design pattern by the Selenium community in test automation for enhancing test maintenance and reducing code duplication. A page object is an object-oriented class that serves as an interface to a real page/screen of your application. In a nutshell, the pattern implies creating a page object class for every application page you want to test and have the tests use the members of this class whenever they need to interact with the UI.

As we add more and more features to a project or increase the automated tests coverage by adding more tests, the risk of ending up with a hard to maintain test project increases.

For example, on the home page of a web application, we might have a menu bar that contains navigation links to different modules. Many automated tests scenarios would be clicking through these menu buttons and execute specific test validation logic. Imagine that the UI is revamped and the menu buttons are relocated to a different position on the home page. This will result in failing tests as scripts will not be able to find some element-locators to perform the required actions. In order to fix those tests, we need to walk through the entire test code to update locators where necessary. Updating element-locators in duplicated test code will consume a lot of time that can otherwise be better used to increase test coverage. And this is just one of the easier to handle scenarios.

To better prove the point, imagine what needs to be changed if a list is replaced with a grid, or a page is completely redesigned. In all these cases, if the tests are executed against a page object class, only that class will have to be adapted.

If we were to summarize the advantages of using the POM pattern it would boil down to the following:

  • Easy to maintain. Once you made your design, if any locator or functionality changes on the web page you know exactly where to change your code.
  • Clean and understandable code. Instead of using the same code all over your test classes, many features are defined within the page objects. Hence the amount of lines of code written is reduced and your test code becomes easier to understand.
  • Helps you point out the UI. Since you create page classes for almost every page of your web application, it is easy to comprehend the functionality and model of your web application at a glance on your test framework.
  • Better test scripts. Your test scripts will contain descriptive and easy to understand code (e.g. homepage.goToLoginPage()) instead of incomprehensible and hard-coded code (e.g. driver.findElement(By.id(“login”)).click()).

    • Writing tests

    A simple example scenario for an automated test is the successful login of the user in the application. When the user enters valid credentials, upon pressing the sign-in button the application will redirect to the home page.

    Based on the above described POM pattern, the test method which validates this scenario could look as the image. As can be seen, all we needed to do in order to write this test is to create an instance of the login page and call methods on this object.

    You have read a few paragraphs of 'Automated UI tests with Selenium'

      Would you like to receive the full article? Please contact netrom@netrom.nl.

    Learn more about UI Tests with the full article,
    contact ronald@netrom.nl
    or call +31 (0)30 782 0111.