Guest Post: Designing a Ruby-based Sauce Test Automation Framework

Designing a Ruby-based Sauce Test Automation Framework – The What and the Why

When we start developing regression test suites for our codebase, we encounter issues such as code duplication, repetition of setup code, searching for required section of code from actual test code, managing different layers of tests such as field level, section level, page level and application level test code. A good test automation framework is built keeping the above design issues in mind. In this blog, we will cover why we should use Page Object Pattern, a design pattern in a test automation framework. We will then create a simple test suite in Ruby to implement this pattern and try executing it on Saucelabs.

The Page Object Pattern Defined:

Every test code that you write will comprise of several components – first the code needed to navigate through and interact with the elements of the page that you want to test. Then, there is the actual test code itself that reviews the content of the page and verifies if the actual results seen on the page matches with the expected results. The architecture of this framework comprises of the following building blocks:

Tests
Actions
Pages
Page Elements

Base class	Description
SeleniumTest	This class requires all the basic methods to start the environment for testing.This class has intializer in which it is possible to specify the Driver TypeIt has method to create browser instance, launch a specific URL in that instance, it can establish connection with database if required, and can switch between frames and windows. This class can also refresh a current URL.
SeleniumAction	This class needs to interact with the pages components and get the task completed. This class can change the pages in the browser or can also bring back the previous status of the pages in the browser. It also interacts with database for various inputs required in pages. And this class can also switch frames and windows.
SeleniumPages	This class is required by both the above class to perform changes. This is to represent the page which is used by both Action and Test class. This class is used to facilitate locating a specific element on a page, one of the ways for which could be to use browser start index and for that it has to know the browser being used.
SeleniumPageElement	This class is required to identify elements on the pages, which are used by actions and tests. This class will identify elements based on id or css or xpath provided by the user and return it to actions and tests. This class can also click a specific element and can wait for some element to appear on the page.

Class Diagram:

Advantages

The advantage of using such a framework is the clear segregation of the functions across the various classes. For instance, now our Test classes will only have to verify and assert test conditions. While the Action classes will handle the required action steps to be taken on the page such as retrieving values or inserting / updating values to change the current state of the system. And the Page classes will manage the interactions of the elements within it with the help of Action or Test classes. This framework also offers the advantages of reusability and maintainability of the test codebase in the long run. (In our further blogs in this series, we will look at implementing a Simple Test Framework on Ruby using Page Object Pattern. We will also write a few simple test cases.)

This guest post was written by Vinodh Balaji Sridharan and Ganesh Kaliannan, Neev Technologies.