How To Implement Data Tables In Cucumber Using Selenium Ruby

What is Cucumber?

Cucumber is used in many languages, including Java, Python, and Ruby. It is very popular with frameworks because it is easy to test methods with assertions covering most use cases.

It is a popular tool for running automated acceptance tests. In short, you create a plain text file (Feature file) that contains descriptions of the scenarios (i.e., different ways a user might interact with your application). You could run Cucumber using Ruby to execute the scenarios and generate a concise report of whether each scenario passes or fails.

Cucumber embraces Behavior Driven Development, which means you write your scenarios in a natural language, speaking to the application as a user would. Cucumber utilizes Gherkin – a lightweight programming language that looks like English.

Gherkin is a Domain Specific Language (DSL), meaning that you have different keywords for different steps in your scenarios compared to standard programming languages such as Ruby, Python, and Java.

Cucumber support for other frameworks and tools

Most Cucumber users use it with Ruby, but it can also be used to test applications written in other languages. For example, you could write your scenarios using JavaScript as a scripting language, and your steps could interact with a web browser rather than a web application.

Cucumber provides support for Capybara in the form of a Capybara driver. Once installed in your test suite, Capybara will launch a browser window before each scenario and navigate to the specified URL and the text in the title bar.

Cucumber also supports Ruby on Rails (ROR), Watir, and Spring framework, among others.

Cucumber syntax

• Features – A feature in the software world is generally a small section of functionality you would like to test. In Cucumber terminology, a feature is an expectation that must be true to pass any scenario. For instance, imagine you want to test if a user can log in with a username and password combination. I will refer to this as the scenario “User can log in”.
• Scenarios – A scenario is how the features are connected. A scenario generally describes what the user should do next, or in other words, what behavior your application should have during that particular flow step. This way, users can see if they have done everything they need and if they still need to proceed forward.
• Description – The description is a narrative description of the behavior that the user should have. It should be written in a natural language and not repeat any information contained in the feature or step definitions. Let’s say a scenario is “User can login”. The description for this scenario will be “The user should see a screen where he can enter his username, and then see another screen where he can enter his password.”
• Given – This is a statement that states what the system should be like at the time of running this scenario (pre-requisites). This allows us to describe the state of reality we need to have for our application to work as expected and pass any subsequent test scenarios. In other words, if no errors are occurring, then we should be able to proceed to the next steps indicating that everything is working as expected.
• When – this is an “if” statement stating what you want the application to do when you run your scenario. Let’s say if a scenario is “User can log in”, then we would write, “When one or more users try to log in they should see a page outlining what they need to do next.
• And – the “and” is the “and then” statement which connects the steps together. It’s like an “if-then” statement, but with two conditions instead of just one. In Cucumber, you write one at the end of every step as it marks the beginning of a new scenario.
• Then – this part is where we check whether our application did what we expected it to do when running our scenario. The Cucumber framework will automatically check that all your “then” steps are true before continuing to the next step in your scenario
• Steps definitions – these are the steps where you specify what should happen in each scenario. They are written in Ruby, and you must specify what the application should do when you run a specific step.
• Cucumber hooks – hooks are a particular type of Cucumber annotation that allows you to use specific code in your steps that you may have written elsewhere. This helps to avoid repetition and errors in your code.

Some examples of Cucumber hooks are :

• Before hook: runs before every scenario.
• After hook: runs after every scenario.
• Setup hook: runs before any scenario.
• Teardown hook: runs after any scenario.
• Step definition hook: runs when the step is about to be executed or has just been executed.

It’s important to note that we can have tagged hooks – Which are used for step definition hooks.

The Cucumber Ruby gem comes with a few additional pieces of functionality that are not related to the Cucumber framework itself. Pieces of functionality such as report generation, database-driven steps, and database-driven reporting are all built into the cucumber gem.

While I’m not going to be covering any of these as it is outside of the scope of this blog on data tables in Cucumber, it is something that you may want to look into if your system has a lot of complicated interactions and requirements for every scenario you have defined.

How to run Cucumber?

Here are some ways to run Cucumber:

• The first is using a DSL (Domain Specific Language). A DSL is a programming language that you write yourself to create the equivalent of English descriptions.
• The second way is using the built-in Rails features, which might be easier for certain programmers to implement if they’re unfamiliar with writing DSLs.
• Thirdly, we can also use actual Ruby code (which is probably more common) – and this is how we will use it to run our tests.

Having gone through the basic functionality of Cucumber syntax, let’s look at data tables in Cucumber.

For developers or testers looking to elevate their skills, you need to look no further. This Selenium Ruby 101 certification can get you in the door at any organization and ready to climb your way to the top.

2M+ Devs and QAs rely on TestMu AI

Deliver immersive digital experiences with Next-Generation Mobile Apps and Cross Browser Testing Cloud

Sign up with googleSign up with Email

Here’s a short glimpse of the Selenium Ruby 101 certification from TestMu AI:

What are data tables in Cucumber?

A data table (or data matrix) is a special type of table that allows us to compare a set of numerical values simultaneously easily. It’s great for displaying data that you would like people to understand at a glance.

Data tables are most useful when working with data that is numerical. Data tables can be found in almost every business, from insurance to airlines.

They are used for displaying numbers and statistics. Still, they can also be used as a simple way of providing information about a range of choices and doing multiple tests for a particular scenario, as we will use today.

Implementing data tables in Cucumber

To implement a data table in Cucumber, you need to create one or more files named after your feature. Let’s look at the breakdown below to understand this.

To create a data table, you first need to create a file named after your feature containing your scenario. Then you add some text starting with “Given” to describe the data that the system should have before your schemas (in this case, a table) is displayed.

Note: Automate Selenium and Appium tests with Capybara framework on TestMu AI cloud platform

Let’s look at a coding example to help us understand data tables in Cucumber better.

How to implement data tables in Cucumber using Ruby?

We will be testing that different users can log in successfully to our test website and use data tables in Cucumber to make it easy to track our results. The data table structure will help us write the test case once and then re-use it with sample data.

Prerequisites for implementing data tables in Cucumber

• Ruby
  Make sure you have Ruby installed on your system. To confirm the version of Ruby you are running, type the below command in your terminal.

ruby -v

To learn more about installing Ruby, you can go through my earlier blog on Selenium automation testing with Ruby. You should see results below, based on the version of Ruby you have on your system.

• Cucumber and Watir gem
  To run Cucumber tests, we must install the gem cucumber, and we do this by running the below commands on your terminal:

gem install cucumber gem install watir

You would expect a successful installation, which you can confirm by using the list command below.

Note: For watir – you need watir, and you do not need to have watir-webdriver listed.

When writing this blog, the latest version of Cucumber was 8.0.0. This version might vary based on the latest version of Cucumber available then.

Implementing Cucumber data tables

• Let’s start by creating the Cucumber folders necessary for this project. Navigate to the folder where you will run your tests and run the following in your terminal.

cucumber --init

We expect to see a couple of folders created that are similar to the ones below.

• To successfully run our tests, we will create four files. We shall go through each one in detail afterward.
• First, let’s create a features_files directory. To do this, type the following into your terminal.

mkdir features_files

• Inside the features_files folder, create a file called the login_tests.feature. We can then type in the code below.

#/features_files/login_tests.rb
Feature: Ecommerce login Feature
 Scenario: Verify ecommerce webpage loads and user can sign in
   Given Ecommerce webpage Login Page loads
   And Ecommerce Login Link is present loaded
   Then Correct Username and Password Should Login Successfully <username> <password>
   And My Account page should display after login
 Examples:
   | username                       | password      |
   | [email protected]          | LambdaTest123 |
   | [email protected]     | LambdaTest123 |
   | [email protected]  | LambdaTest123 |
   | [email protected]       | LambdaTest123 |

Then create another directory inside features called page_object, create a file called login_page.rb. This will be where we shall write our page object functions and use them in our tests. To learn more about Page Object Model, go through our earlier blog on Page Object Model in Selenium.

#/page_object/login_page.rb
class LoginPage
 def username_link
   $browser.link(text: "Forgotten Password")
 end
 
 def username_textbox
   $browser.input(id: "input-email")
 end
 
 def password_textbox
   $browser.input(id: "input-password")
 end
 
 def login_button
   $browser.button(value: "Login")
 end
 
 def account_header
   $browser.link(text: "Edit Account")
 end
end

Note: Run your Cucumber test scripts across 3000+ real browsers and OS. Try TestMu AI Now!

What are Page Objects in Cucumber?

Page objects are a way of creating test objects specific to your application. In Cucumber, they are used to create and manage page objects so that we can interact with third-party code and databases.

They come in handy when the object you’re writing must not be directly dependent on Rails’ usual classes, models, or collection structures.

Think of page objects as ‘functions’ for creating object instances – except they don’t just create objects based on classes or named collections – they instead create instances based on whatever values you input them in the text you supply them with.

When do you use page objects?

The page object is the simplest way to separate locators from the rest of the application. A new class can easily be added to a page object that concentrates all locators used on that page. Therefore, it is best to separate these locators so they do not interfere with testing. To learn more about locators, go through our earlier article on locators in Selenium.

In the next section of this article on implementing data tables in Cucumber, we will look at some of the benefits of using page objects.

What are the benefits of using page objects?

Using page objects helps us separate locators from functional code by defining them as properties on a ‘page object’ class definition.

• Ability to define locators on multiple user interface pages without duplicating locator definitions or coding.
• Immediate integration with existing test automation frameworks with minimum code changes required by the automation team.
• Elimination of the need for test automation frameworks to support session-level locators when viewing multiple pages.
• The ability to specify a relative path for each page object.

When creating a page object, it is generally required to define properties that describe the page containing the page object.

It’s important to note that we do not have to link each locator’s definition of a test automation framework with each page object. During testing, the recommended approach for an automation team is to reference a single class definition file rather than hundreds of locator definitions in each test script or have separate locator definitions grouped in a specific order and valid naming conventions. This makes it easier to find a page object.

For the third file, we shall create a file under step_definitions(a folder that already exists) and create a file called ecommerce_steps.rb.

Here, we will have all our step definitions for our Cucumber test. For example, we will have a function for navigating to the login page that we will use in the login scenario.

When creating a page object, it is generally required to define properties that describe the page containing the page object.

It’s important to note that we do not have to link each locator’s definition of a test automation framework with each page object. During testing, the recommended approach for an automation team is to reference a single class definition file rather than hundreds of locator definitions in each test script or have separate locator definitions grouped in a specific order and valid naming conventions. This makes it easier to find a page object.

For the third file, we shall create a file under step_definitions(a folder that already exists) and create a file called ecommerce_steps.rb.

Here, we will have all our step definitions for our Cucumber test. For example, we will have a function for navigating to the login page that we will use in the login scenario.

#/step_definistions/ecommerce_steps.rb
Given(/^Ecommerce webpage Login Page loads$/) do
 $browser.goto "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
 $user_session = LoginPage.new
end
 
Then(/^Ecommerce Login Link is present loaded$/) do
 assert($user_session.username_textbox.name, "email")
 assert($user_session.password_textbox.name, "password")
end
 
Then(/^Correct Username and Password Should Login Successfully (.*) (.*)$/) do |username, password|
 puts "------"
 puts username
 $user_session.username_textbox.send_keys(username)
 sleep(3)
 $user_session.password_textbox.send_keys(password)
 sleep(3)
 $user_session.login_button.click
end
 
And(/^My Account page should display after login$/) do
 assert($user_session.account_header.name, "My Account")
end

Lastly, we will edit our env.rb file, which is under the support to have the following details.

#/support/env.rb
require 'rubygems'
require 'watir'
 
Before do |scenario|
 $browser = Watir::Browser.new :firefox
 $browser.driver.manage.window.maximize
end
 
After do |scenario|
 $browser.close
end

How to implement data tables in Cucumber on cloud grid?

Selenium Grid is a tool for distributing the load across multiple browsers. Selenium Grid can be used to run tests on different operating systems and browser configurations simultaneously. The grid configuration will control which browsers run the tests and how many of them at a time.

To run this on the cloud grid like TestMu AI, you would need to replace the local webdriver with the remote webdriver. Cloud-based cross browser testing platforms like TestMu AI provide you with an online browser farm of 3000+ browsers and operating systems to perform Selenium Ruby testing at scale. Here’s a glimpse of TestMu AI online Selenium Grid:

You can also subscribe to the TestMu AI YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress E2E testing, CI/CD, and more.

Replace the following code on the file

/support/env.rb

On local Selenium Grid:

#/support/env.rb
require 'rubygems'
require 'watir'
 
Before do |scenario|
 browser = Watir::Browser.new :firefox
 $browser = browser
 $browser.driver.manage.window.maximize
end
After do |scenario|
 $browser.close 
end

On cloud Selenium Grid:

#/support/env.rb
require 'rubygems'
require 'watir'
 
Before do |scenario|
 username= "#{LAMBDATEST_USERNAME}"
 accessToken= "#{LAMBDATEST_ACCESS_KEY}"
 gridUrl = "hub.lambdatest.com/wd/hub"
 
 capabilities = Selenium::WebDriver::Remote::Capabilities.new
 
 capabilities['platform'] = 'Windows 11'
 capabilities['name'] = 'Cucumber Login Tests'
 capabilities['build'] = 'Cucumber Test v.1'
 capabilities['browserName'] = 'Firefox'
 capabilities['browserVersion'] = '100.0'
 
 $browser = Watir::Browser.new(
   :remote,
   :url => "https://"+username+":"+accessToken+"@"+gridUrl, :desired_capabilities=>capabilities)
  
 $browser.driver.manage.window.maximize
end
 
After do |scenario|
 $browser.close

Remember to export your Username and Access Key in environment variables via your terminal with the commands below.

For Linux/macOS: export LAMDATEST_USERNAME="YOUR_USERNAME" export LAMDATEST_ACCESS_KEY="YOUR ACCESS KEY"

For Windows:set LT_USERNAME="YOUR_USERNAME" set LT_ACCESS_KEY="YOUR ACCESS KEY"

Checking results on TestMu AI:

You should see the tests fire up on the Automation Dashboard and the results displayed on the right as shown.

You will notice that the number of rows on the data tables is equivalent to the number of tests that are run, which is precisely what we expect, and this also highlights why data tables in Cucumber are essential.

You can view your test results and overall performance on the TestMu AI Analytics Dashboard. From the Test Summary section, you can easily see which tests failed and which passed, as well as how many. You can also navigate to the Test Overview page, where you can see a breakdown of all test runs, including individual test performance.

More debugging tips while implementing data tables in Cucumber

If you are getting errors on Cucumber and want to know where the error exactly is happening, then we need to take one step back. Even though Cucumber tries to create a test for all your features, it doesn’t always do so due to duplicate scenarios or missing data tables in Cucumber.

To fix this, you need to navigate the tests and change the test itself. If you still have issues, you can dive deeper into your code using a debugger.

A debugger is a tool that allows you to step into your code, change things like variables and rerun the same scenario. The debugger enables you to see what’s happening as you run your tests step by step.

Once we have what is causing the error, we can look at the failing scenarios and fix them. Remember that some features might not work in a certain environment or browser. So what works for me might not work for you. So don’t be afraid to change these scenarios and add more complex ones.

We can use a gem called Ruby-debugger that gives us the lines in our code that are failing by following these steps.

Note: Try LT Debug Chrome Extension for debugging websites!