Test Automation of Web Applications using Cucumber with Ruby Core Framework

Behavioral Driven Development (BDD) is associated with the test-driven development. It is a way to communicate example based software among the developers, Testers, Business Analysts Product owners and other team members.


What is Cucumber?

Cucumber is a BDD automation test environment which describes acceptance criteria. BDD develops scenarios under the feature file with or without examples using ‘Gherkin’. Gherkin provides the ‘Domain Specific Language’ and a simple way to understand between technical and non-technical members. It’s described in ‘Simple English’ that anyone can understand.


How to Plant a Cucumber in our environment?

Cucumber is a command line tool which describes the specification of plain English text files called ‘Features’. It examines scenarios to test and executes scenarios against the system. Each scenario is a list of cucumber line that follows basic syntax rules. The set of rules is described as ‘Gherkin’ Language and Cucumber also combines with a set of step definitions, which is mapped to the feature file in each line with the steps into Ruby to carry out execution which is being described by each line. Step definition is also a bridge between one or two lines of ruby that is assigned to a library of support code, particular to the field of system and would generally be found in the automation library.

This automation library demonstrates that the ruby code step definition executes without an error. If all steps are given correctly, then end of the scenario is given ‘passed’ status or if any of the steps is given an error then execution is stopped and is given an ‘error’ status. Cucumber generates the final status of each scenario and we can analyze the final status of each step. Cucumber stacks can be given as follows.

Figure 1: Ruby Test Framework Stack

 Figure 1: Ruby Test Framework Stack

Ruby framework to execute Cucumber feature file

In the above diagram, the first four of the checklists relates to the business perspective and the other four of the checklists relates to the technical perspective. Ruby is an open source language and has much stronger communication with Cucumber and easily handles different web browser technologies. Found below is the systematic diagram to illustrate how the ruby framework build under the Cucumber, Selenium and Waiter techniques.

When implementing the BDD framework in a local machine, selecting the stabilized version is a must. The current automation tests use the following version ‘ruby 2.0.0p645 (2015-04-13) [i386-mingw32]’ and use the URL http://rubyinstaller.org/downloads to install it.

Figure 2: Ruby Framework UML

 Figure 2: Ruby Framework UML

How to implement the Feature Step definition” using ruby mine ?

According to the agile testers, they write their feature files in the first week of sprint and build on it in their own location with the test data which they have used with valid and invalid scenarios, as well as considering boundaries. Then developers get a clear idea of what the testers are going to be tested in this feature. This feature file includes the background; if the example exist, it would be given as a scenario outline or as many scenarios. The feature file language is defined as ‘Cucumber language’ format.

Feature File Format

Feature file starts with the ‘.Feature extension’. After creating a new project inside the ‘Ruby Mine’ and a folder called ‘Feature’ has to be created, after right clicking on the project and adding the directory to the current project and renaming it as ‘Feature’. And add files to the feature folder and save it in as .Feature format. Gherkin is given special keywords to identify the user scenarios separately. These keywords depend on the simple English words and the user can easily understand these keywords when reading the first time whenever the technical depth is highest. It can be given as a feature, Background, Scenario/Scenario Outline, Given, When, And, Then, Examples,*.


Feature is the starting point of the file and the user can identify the feature specifically using this keyword. It’s summarized using the whole scenarios to one or two sentences.


The background is stored in a set of scenarios are given in the feature file and reduces the duplicate scenarios, but the background is not much necessary in the scenario. It is only reduces the duplicate steps in the scenarios. It’s written before a scenario or scenario outline. Background increases the reliability and readability of the feature. An example for ‘Background’.

Feature: Send Activation Code via E-mail
Send Activation Code for the specific user whenever the device configuration is successful to the specific user, the system sends an activation code that is a randomly generated number to the system.

Given I have configured the device authentication.
And I type the valid email address
Scenario: Send an Activation Code
When I type the valid e-mail address
And I click on the ‘SEND ACTIVATION CODE’

Scenario: Send a resend E-mail Activation Code
Given I am in the Device Activation Dialog
When I click on the ‘RESEND ACTIVATION CODE’ button
Then I should see the valid activation code


Scenario and Scenario Outline

The Scenario is a small subset of the feature which defines the specific incident. One feature file normally consists up to five or twenty scenarios, including valid and invalid scenarios and also some of the scenarios consist of one or more test examples and we can use these scenario outlines for the above incidents. If the Scenario Outline keyword is defined, we would need to give the test scenario examples with the Example keyword.

Feature: Value card Merchant Agreement functionality
#Tenant User login as a valid username and password

Scenario Outline: A new merchant agreement with valid details

Given I login as a tenant user using “Rambutechtenant@xxx.com”
And valid password as “xxxxx”
And I click on the “Merchants” button
And I click on the link “<arg>” link
And I select Merchants from the drop down
And I select on the Program from the drop down
And I type transaction period days
And I click on the check boxes in the operation section
And I type the Correct Transaction Period (Days) text boxes
When I click on the save button
Then I should see the merchant agreement save successfully


| arg |

| Add a Merchant to a Program |


Given, When, Then

‘Given’ keyword defines the precondition of the feature. It has given precondition of the each scenario with or without background section. It defines the actual action that the specific scenario is talking about. Then it defines the post condition of the current scenario. The keyword is along with the ‘When’ keyword and gives the actual specification to the specific user. The scenario lines are interconnected by using ‘And’ keywords. The keyword is intermediated with the ‘When’ and ‘Then’ words.

Step Definition

The step definition is handled in the system in a way of test ruby automaton. It’s intermediated of business scale and program scale. The step definition in a ruby framework can be written in Ruby language. Ruby Implementation can happen in the Ruby language. The step definition has two way communicators,

  1. Plain text translates the step definition in Ruby
  2. It handles the actual behaviors of the system work

The integration process of the step definition in Ruby framework includes the first step to build a folder name called step definition and then create ruby steps inside that folder.

How to develop one feature inside the Ruby Frame work?

First, Write the feature file using Gherkin and after going to each and every line, Write the step definition for the specific line using ruby that can recognize each Gherkin line. Step definition defines the steps for conducting a specific feature. The step definition can be generated for a selected line by right clicking on the bulb icon of the selected line.

Figure 3: Step Definition creation for each step

Figure 3: Step Definition creation for each step

This framework includes the browser compatible function, and tests can be written for various web browsers. The ‘Web browser’ keyword always starts with the ‘@’ sign and the ‘Browser’ keyword. A new variable can be created for the browser.

The examples of various web browsers can be given as follows,


Figure 4:: Different Browsers Variable in step definition

Figure 4: Different Browsers Variable in step definition

All of the above browsers are compatible with the current web driver downloader, else it would give an error from the web driver and it would be unable to run the feature file.


How to handle the step definitions according to the web application?

The step definition handling is different from one step to another step from the feature file. It can be different from an UI element to the other, such as drop down, text field, label, link, div etc. Step definition is basically implemented inside the Ruby framework which is identified in the ID of the above UI elements using firebug or similar software. The ID of the each element is fetched and this ID is called through the step definition lines. Following is an example of step definition code of the common UI element web application for the Value Card Version 1.0.  

0.1 Text Field

The following is the text field code which passes the text field ID and set the argument to the feature file.

Figure 5: Text Box Step DefinitionFigure 5: Text Box Step Definition

In the first line of step definition, combined with the web page real id for the given text field id and combined it with the argument of the feature. Then need to send the special keys to an element or browser page, uses the send_keys method, with a return key word of text field that would like to return for the current step. End keyword is must after finish the each line for the current scenario.

0.2 Drop Down

Figure 6: Drop Down Step DefinitionFigure 6: Drop Down Step Definition

Passed the dropdown id with the select_list keyword and give the selection value of dropdown. And send this value to the browser.

0.3 Button

Figure 7: Button Step Definition
Figure 7: Button Step Definition

Get the argument value of feature file and pass it with a text. Set the URL of the button with the “go to” keyword and send that values to browser.

0.4 Link

Figure 8: Link Step Definition
Figure 8: Link Step Definition


How to generate the automation test result after the test execution?

Finally, Rubymine can generates the test result file according to the feature file execution steps including the scenario. The framework is given the test runner dialog and after the successful test execution, it can save the test output and generate the output test result file. The Export format of the Ruby framework is HTML, XML and custom generated template.

Figure 9: Test Result Program
Figure 9: Test Result Program


Benefits of the Feature File using Ruby Mine

  • Find and fixed defects easily
  • No time consuming for bug fixes
  • More reliable scenarios
  • More understandable syntaxes and easy to execute scenarios
  • Browser compatibility




Author: Harshani Weerasooriya

Leave a comment