Why Gherkin is good, and Cucumber is not

Jan 20, 2025

Why Gherkin is Good, and Cucumber is not.

It's one of those rainy days in Bengaluru, when you are under slept, over fed and have read/heard the opinions on a topic close to your heart. In my own experience of writing frameworks to build Cucumber tests (using Java+Selenium) and maintaining them, Ive felt that do we really need it? And how will the future of BDD evolve with technologies like AI.Here's my raincheck (pun intended). So first the basics: What is Gherkin and What is Cucumber?Gherkin is a domain-specific language tailored for BDD. It allows teams to write human-readable scenarios that describe the desired behavior of software systems. These scenarios follow a simple structure using keywords like "Given," "When," and "Then," making them accessible to both technical and non-technical stakeholders. The primary goal of Gherkin is to create a shared understanding of how a system should behave under various conditions.Here is a sample BDD scenario in Gherkin:



Cucumber, on the other hand, is a tool that interprets Gherkin scenarios and facilitates their execution. By mapping Gherkin steps to code implementations, Cucumber enables automated testing of the described behaviors. Originally developed for the Ruby programming language, Cucumber now supports multiple languages, including Java and JavaScript.Key Differences Between Gherkin and Cucumber

While Gherkin and Cucumber are often mentioned together, they serve distinct purposes in the BDD framework:


Also, Cucumber as opposed to popular belief is not a testing tool:


(Thanks to Nikolay Advolodkin for pointing in this direction on his podcast)

Here are a few main challenges with Cucumber

Despite its utility, Cucumber introduces several challenges that can complicate the development and maintenance of automated tests:

1. Glue Code Complexity

Cucumber relies on "glue code" to connect Gherkin steps to their corresponding code implementations. This glue code can become unwieldy, especially in large projects, leading to difficulties in managing and updating tests. The need to write and maintain extensive glue code can cancel the simplicity that Gherkin aims to provide.

Here’s an example snippet of glue code:

@Given("a user is on the homepage")
public void userIsOnHomepage() {
    driver.get("https://example.com");
}

@When("the user clicks on the search icon")
public void userClicksSearchIcon() {
    driver.findElement(By.id("search-icon")).click();
}

@Then("only one product should be displayed as the result")
public void verifySingleProductDisplayed() {
    List<WebElement>

This glue code requires extra effort, and any change in step phrasing or application behavior can break the tests, requiring updates across multiple files.

2. Implementation and Maintenance Overhead

As applications evolve, the Gherkin scenarios and their corresponding step definitions require regular updates. In Cucumber, even minor changes in requirements can necessitate significant modifications to the glue code, increasing the maintenance burden. This overhead can slow down development and testing cycles, making it challenging to keep tests in sync with the application. Just read the example above and tell me if you disagree.

3. Tight Coupling with Grammar

Cucumber enforces a strict adherence to Gherkin syntax, which can limit flexibility in writing test scenarios. This rigidity can stifle creativity and make it difficult to express complex behaviors succinctly. Moreover, any deviation from the expected syntax can lead to test failures, even if the underlying functionality is correct.

Still can't believe it? No problem. Recently a friend and industry expert Benjamin Bischoff 's post started some really good conversation on a Linkedin post: (Reference comments below).

Note: Interestingly, the post was about something totally different 🤗


Writing Abstract Tests and Promoting Cross-Team Collaboration for BDD

Scroll a few points above and read the Gherkin example (yes, do it). Doesn't it feel fluid?

One of the best things about BDD is how it brings everyone to the table—from developers to testers to business folks. Writing abstract tests is a great way to make this happen. Instead of focusing on the nitty-gritty details of implementation, these tests keep it simple and stick to what the system should do, not how it does it.

Here’s why abstract tests work wonders:

  • They speak everyone's language: Since they’re written in plain, easy-to-understand terms, anyone on the team can chime in, whether they’re technical or not.

  • They’re future-proof: By steering clear of code-specific details, these tests stay relevant even when the tech stack changes.

  • They bring people together: When tests are accessible to everyone, it fosters collaboration and makes quality a shared goal.


Future of Testing is "Collaborative"

While Gherkin is great for specifying software behavior in a clear and collaborative way, traditional tools like Cucumber can sometimes complicate the process. We are seeing a few implementations, where teams are happily going back to BDD and Gherkin to specify their stories, and leave the execution to solutions like Hercules and similar AI-driven Agents. The future of testing lies in breaking free from the rigid glue of the past and embracing intelligent, agentic automation.

What do you say?

balance cost, quality and deadlines with TestZeus' Agents.

Come, join us as we revolutionize software testing with the help of reliable AI.

© 2025 Built with ❤️ in 🇮🇳. All Rights Reserved.

balance cost, quality and deadlines with TestZeus' Agents.

Come, join us as we revolutionize software testing with the help of reliable AI.

© 2025 Built with ❤️ in 🇮🇳. All Rights Reserved.

balance cost, quality and deadlines with TestZeus' Agents.

Come, join us as we revolutionize software testing with the help of reliable AI.

© 2025 Built with ❤️ in 🇮🇳. All Rights Reserved.