Enhance Your Strategy with TV+ Planning Insights!

Get free access to advanced audience insights, benchmark competitors, and uncover new opportunities. Revolutionize your TV advertising now!

UI Test Automation Design

Kateryna Semenova
Published: May. 19, 2015

Auto tests design problems

Your success in test automation depends not only on selected tools but also on how you design your tests.

First, consider an example of typical test automation that does not use any abstraction. This is a simple login scenario automated using Selenium WebDriver and written in Ruby:

Image of code showing simple login scenario automated using Selenium WebDriver

There are several problems with this approach:

  • No separation between the test method and control locators
  • Locators would be spread in multiple tests
  • If developers make any small UI changes it would be difficult to update your tests

So our goals are:

  • Reduce code duplication
  • Enhance test maintenance

Page Object Design Pattern

One of the solutions is to use Page Object Model. Page Object is a Design Pattern, which has become popular in test automation for enhancing test maintenance and reducing code duplication. A page object is an object-oriented class and contains the representation of the page with the services the page provides via methods. The tests then use the methods of this page object class whenever they need to interact with that page. The benefit is that if the UI changes for the page, the tests themselves don't need to change; only the code within the page object needs to change. Subsequently all changes to support that new UI are located in one place.

The Page Object design pattern provides the following advantages.

  1. There is clean separation between test code and page specific code such as control locators and layout.
  2. There is a single repository for the services and operations offered by the page rather than having these services scattered throughout the tests.

In both cases this allows any modifications required due to UI changes to all be made in one place.

Diagram showing relationship between web page, page class, test, and base page

How to implement your Page Object Model

  • For each web page you have a Page class. All control locators and methods for that page should be put in this class.
  • All test logic and verifications should be put in test classes.
  • All shared controls or methods should be put in a base page class.
  • A Page class does not necessarily need to represent an entire page. It could be used to represent components on a page like frames.

Creating Login page class with page-object gem

To create the Login page class for our scenario above we will use Page Object gem (see more info here https://github.com/cheezy/page-object)

Image showing how to create a Login page using an Page Object gem.

Usage of the page would be:

Screen Shot 2015-05-19 at 11.28.50 AM.png

Creating your page object

Page-object gem supports both watir-webdriver and selenium-webdriver. The one used will be determined by the driver you pass into the constructor of your page object. The page object can be created like this:

Screen Shot 2015-05-19 at 11.29.02 AM.png


Screen Shot 2015-05-19 at 11.29.10 AM.png

Test Data Design

Another problem that projects may face is long test execution time due to an increasing number of tests. The solution is to run tests in parallel, which is only possible if test data is designed properly. Ideally your tests should not depend on other tests data or change the data of other tests. Finally, tests should run on all environments: local, CI and deployed environments such as production.

Diagram showing the solution of running tests in parallel by designing test data properly.


For UI test automation in Simulmedia we use the following tools:

If you want to start your automation process by using Ruby language + Cucumber + Watir WebDriver + Page Object gem check out the following book from Jeff Morgan: Cucumber and Cheese