In our last article, we talked about BDD philosophy and how Gherkin with its simple set of rules, facilitates the description of system behaviors and sets the foundation for automation. But how does a Gherkin test translate into an automated test? This is where tools like Cucumber and Specflow come in.
Cucumber is a tool which supports Behavior Driven Development (BDD). The key feature of Cucumber is its support for Gherkin, the domain-specific language of BDD.
Cucumber interprets Gherkin syntax and executes the corresponding test steps, thereby promoting test automation practices within agile software development teams.
Cucumber implementation are available in multiple programming languages like Java, Node.js, Ruby, C++, Scala, Kotlin, Python, Perl, Go and many more.
Cucumber and Gherkin are used in behavior-driven development (BDD) to turn business requirements into automated tests. They help improve communication between developers, testers, and business stakeholders. If you’re unfamiliar with them, you might be wondering how these tools work together and why they’re valuable for testing teams.
For many teams, relying solely on manual testing isn’t enough. Bugs and errors can slip through, even with the most thorough checks. Cucumber and Gherkin help address this problem by simplifying the process of writing tests that align with how the application is meant to behave.
Using Gherkin, you write tests in simple language that everyone can understand, while Cucumber executes those tests automatically. This helps improve collaboration among all team members, including non-technical stakeholders, as they can read and understand test scenarios without needing programming knowledge.
Gherkin is the language used to describe the tests that Cucumber runs. It lets you write feature files in a format that is easy to read and understand, regardless of whether the reader is technical.
These feature files define scenarios and the expected behavior of your system. Gherkin uses keywords like Given, When, and Then to break down each step of the test in a way that can be followed by both technical and non-technical team members.
AIO Tests helps not only in writing BDD tests, but supports the end to end BDD ecosystem, from authoring to generating feature files for Cucumber and all the way till reporting results from Cucumber automation runs.
Gherkin Tests can either be created manually or by providing a story as input to AIO Tests AI Assistant! Let’s start off with manually writing a Gherkin test in AIO Tests for a simple user story. Or better still, let's do both - manual and AI assisted!
If you already have existing feature files, then AIO also has an "Import Feature files" ability to bring in existing automated tests in AIO.
Create a case and on the Steps screen, select the BDD/Gherkin steps type.
As steps are typed in, they get stored in a steps repository and then can be re-used. While automation, a similar concept works with step definitions, wherein steps can be reused across multiple scenarios. Save and our first case is ready!
Head over to the AI assistant and select the story to generate BDD cases or simply add relevant text in the Text Based option. In the below screenshot, the AI assistant has generated 15 cases. Cases can be edited and steps can be added right where the cases are being generated.
Gherkin documents are stored in .feature files. Each feature file can contain multiple scenarios to test a particular feature. AIO Tests provides a simple export functionality to get the feature files ready, providing a quick base for automation of cases.
Note Jira Story filter has been applied to export the cases to a feature file.
A .feature file gets exported with all the selected cases becoming scenarios. The feature file starts with the feature keyword which is the title text of Jira story. All steps are exported as scenario steps. The testcase key from AIO is added as tag to the Scenario, which forms the mapping between the automated code and the AIO case.
Cucumber executes each step in a scenario one at a time, in the sequence in the file. When Cucumber tries to execute a step, it looks for a matching step definition to execute. Step definitions can be written in any language. The below shows the Cucumber Java library providing the conventions to write the step definitions.
Once the code is written to test the application, the inbuilt json reporter of Cucumber can be used to generate a local json report. In Java, with JUnit or TestNG bindings, the @CucumberOptions annotation provides a way to setup the Cucumber arguments.
@CucumberOptions(
features = "src/test/resources/features",tags = "@JREQ-NVTES-11",
glue = {"com.aiotests.samples.stepdefs"}
plugin = { "pretty", "json:target/cucumber-reports/ProductListingResults.json"})
Once the JSON report is generated, it can simply be exported in AIO Tests using an AIO Tests' APIs or by using AIO's Jenkins or Azure Devops plugins.
A sample report updated in AIO shows the step level results for each step in the Gherkin scenario. Time taken to execute the case and actual failures are captured at the step level giving a complete view of execution.
And that's it! We have written our first BDD case, exported it, automated it in the tool of our choice and reported the automation run results in AIO Tests. Book a demo to see how AIO Tests powers accurate testing.
.svg){kind=icon}
