Cucumber Framework: A Complete Introduction

Artem Golubev

When developing a product, all stakeholders must first agree on the specifications. This can be incredibly challenging in fast-paced agile environments where a lot is needed to be accomplished in a limited amount of time. Additionally, as code and test scripts are written in technical languages, misunderstandings and miscommunications can easily lead to gaps between client requirements and actual development output. To address this issue, Behavior Driven Development (BDD) is a solution that can be implemented with the help of tools such as Cucumber.

What is Cucumber?

Cucumber is a BDD tool, a software development methodology aiming to enhance collaboration and communication between developers, testers, and business stakeholders in the development process. Cucumber is written in the Ruby programming language and allows development teams (including QA) to write tests in plain text using the Gherkin language, which is a business-readable, domain-specific language. These tests serve as specifications that describe the behavior of the system and can be executed to verify that the system behaves as expected. The results of these tests are then reported back to stakeholders in a human-readable format, making it easier for non-technical stakeholders to understand and track the progress of the development process.

Cucumber channels BDD and thus, the focus stays on the specifications. These specifications need to be outlined in such a manner that all involved can interpret them without requiring explicit programming language or technical background. This brings us to Gherkin, which is a syntax used in Cucumber to make this collaboration possible.

The Gherkin language

Gherkin is a set of grammar rules that makes plain English text structured enough for Cucumber to understand. With Gherkin at the heart of Cucumber, you can achieve:

• Unambiguous requirement specifications
• Automated tests using Cucumber
• Documentation of scenarios/examples to depict how the system behaves

The Gherkin syntax requires you to list out the specification in the Given-When-Then format. Given refers to the scenario, When refers to the conditions, and Then refers to the expected outcome. It supports many spoken languages, thus allowing a larger user base to adopt BDD into their development process. Gherkin documents are stored in .feature text files and are typically versioned in source control alongside the software.

How does Cucumber help with test automation?

Using the BDD process, all stakeholders agree upon the specifications, that is, how the system will behave. They are written using Gherkin. Cucumber as a tool lets you write these specifications and also the code for these steps. The code is what gets executed during automated testing.

Now let us try to understand how Cucumber, with the help of Gherkin, enables test automation. Cucumber uses the concept of feature files and step definition files. A feature file comprises the specifications in the form of scenarios. They are written using Gherkin syntax.

Each of these statements has to be defined, that is, functions are coded in step definition files. So if we consider an end-to-end flow, the steps in Gherkin are matched with step definitions, essentially pieces of code that manipulate the system.

Step definitions can be written in various programming languages. Cucumber supports many mainstream programming languages, such as Ruby, Java, C#, JavaScript, Python, PHP, and Perl. You can also run your tests in parallel using Cucumber-JVM. Some options to help with parallel execution are JUnit5, JUnit4, TestNG, and CLI. You can read further about this here.

Cucumber uses report plugins to portray the execution results. Some of these plugins are built-in, while others have to be installed separately.

# The first example has two steps
Scenario: Maker starts a game
  When the Maker starts a game
  Then the Maker waits for a Breaker to join
  
# The second example has three steps
Scenario: Breaker joins a game
  Given the Maker has started a game with the word "silky"
  When the Breaker joins the Maker's game
  Then the Breaker must guess a word with 5 characters

Tips for writing effective automation scripts using Cucumber

Some pointers to help better organize your project and ensure effective writing are as follows.

Create a separate file for step definitions

Although you can keep all your step definitions in a single giant file, it is advisable to create smaller step definitions files. Also, consider this segregation based on the complexity of the modules. So if a big project is made of 3 modules, you ought to create 3 different step definition files.

Utilize helper methods to avoid redundancy in step definitions

If you have multiple steps opening different browser tabs, then writing separate definitions will lead to clutter. Instead, use helper methods. In the mentioned example, the underlying action of opening a browser tab is the same. So here you can write the step as

@Given("I go to the {string} page")
  webpageFactory.openPage(webpage);
}

Avoid sharing states between scenarios

Being able to write reusable and concise code is a good practice. When you share states between scenarios, it can lead to tightly coupled tests that cannot be run independently. Moreover, debugging and code refactoring can be a challenge in such scenarios. However, you might want to share states between scenario steps. You can do so by using some techniques mentioned here.

Challenges with using Cucumber

Though Cucumber is a popular choice for BDD, it has numerous downsides that are important to know before you decide to adopt it. Gherkin is meant to make definitions easier; however, it can be quite tricky to use. Even though it is supposed to mimic the plain English language in theory, the awkward format makes it challenging to use.

Coming up with the test scenarios is a collaborative process. Any modifications to the existing suite involve a discussion between the various stakeholders, updates to the step definition file, and changes to the steps. This tends to become a burden on testers. Moreover, updating changes to existing test cases can be a pain since not everyone may know or understand how the code flows in the step definition file.

Though Cucumber is quite effective in bridging some of the communication gaps between technical and business stakeholders, it does make the automation framework somewhat bulky since it is an additional step of overwriting code. This can be counterproductive in situations where a huge number of tests need to be run on a daily basis.

Is there a better alternative to Cucumber?

As widespread as Cucumber is for BDD, it has its core limitations, which testRigor easily overcomes. If you’re not familiar with testRigor yet, it’s a powerful no-code AI-enhanced test automation tool for functional end-to-end testing, and it supports BDD out of the box. Perhaps the most significant advantage is eliminating a whole step since in testRigor, you can write your executable specifications in plain English. Regular test automation tools require you to include implementation details (such as element locators); however, testRigor doesn’t need them.

So, in other words, you write your executable BDD specifications in plain English text in testRigor, then developers code the feature, then you execute your previously written tests – and they should pass. It’s actually that simple. There are no step definition files, and no additional complex structure or dependencies are needed. And since it’s a cloud-hosted system, the whole team can access and collaborate from anywhere.

Let’s consider the example of an e-commerce website where you need to check that the pagination buttons are disabled appropriately if the user is on the first or last page.

In BDD Gherkin syntax, it will look something like this:

Given the user searches item through the search bar

When the filter is applied and user has scrolled to the bottom of the page and is on the first page of results

Then the “previous” button should be disabled

enter "desk supplies" in "Search"
click on "Search"
select "Get it tomorrow"
scroll down up to 10 times until page contains "Next"
check that "3" is to the left of "Next"
check that "Previous" is disabled

This test code is enough for testRigor to understand what it needs to do. There is no need for step definition or additional coding.

Interested in learning more about testRigor to see if it will be a good fit for your development process? Drop us a request below, and someone from our friendly team of experts will reach out!