Implementing Cucumber Scenario Outlines in BDD Frameworks
Behavior-driven development (BDD) is an agile software development practice that enhances the collaboration between stakeholders and developers by using simple, domain-specific language to describe system behavior.
One of the most powerful tools in BDD is Cucumber, which is used to write clear specifications. It can also be used in testing, with most commonly used programming languages, such as Java, Python, or C#, and can be integrated with UI frameworks, such as Selenium, or used for API testing.
Scenario outlines are part of Cucumber’s Gherkin syntax, used to write executable specifications. Unlike regular scenarios that define a single concrete example, scenario outlines enable the specification of multiple examples in a tabular format.
Differences Between Scenario and Scenario Outlines
Scenarios in Cucumber represent a test case written in the basic form of given-when-then. The Gherkin language allows these test scenarios to be written in plain English (and other languages) so they can be easily understood and even written by non-technical people. The step definitions, which represent the implementation of the steps, are created in separate files.
For some functionalities, it makes sense to repeat the same scenario using different test data - you probably know this as data-driven testing. In Cucumber, this is done by using the Scenario Outline with an examples table that contains the sets of data to be used. Each example is counted as a separate test.
Cucumber Scenario Outline Syntax
The typical Cucumber project contains feature files, where the cucumber tests are defined, and the step definition files, with the implementations of the steps.
A feature file should represent a requirement specification, and the scenarios used to test it. The basic syntax for a simple Cucumber scenario is this:
Scenario: Invalid login
Given I navigate to the login page
When I enter invalid credentials
Then I receive an error message
The scenario can also contain variables, which will be treated as such in the step definition.
Scenario: Invalid login
Given I navigate to the login page
When I enter username test and password invalid
Then I receive an error message: "Invalid login".
The values “test”, “invalid”, and “Invalid login” will be treated as variables. Now let’s see what happens when we want to try different combinations of the provided variables - we could end up with multiple scenarios, identical save for the variable values, or use the scenario outline, which allows us to use a table where we define the different data combinations:
Then I receive an error message: "<error message>".
Examples:
| username | password | error message |
| test | invalid | Invalid login |
| test | | Please enter the password |
| | invalid | Please enter the username |
The combination of data is written under the “Examples” keyword, inside a table. The headers of the tables are the variable names, then each row represents the combination of data. Each example inside a Cucumber feature will be treated as an individual test case.
Examples Table vs Data Tables
The examples and data tables may look similar, but they serve different purposes. The main difference is that the examples are used to implement data-driven scenarios, while data tables are used when the scenario steps need to use multiple variables.
A data table can be used like this:
Scenario: Invalid login
Given I navigate to the login page
When I enter the credentials
| username | password |
| test | invalid |
Then I receive an error message: "Invalid login".
or like this:
Scenario: Invalid login
Given I navigate to the login page
When I enter the credentials
| username | test |
| password | invalid |
Then I receive an error message: "Invalid login".
Data tables are especially useful when the steps require multiple variables, and they are easier to read than when each value is written inside the step.
Working with Data Tables and Scenario Outline
Data tables and scenario outlines can also work together. The name of the variable will be provided inside the data table and then reused in the examples table.
Scenario Outline: Invalid login
Given I navigate to the login page
When I enter the credentials
| username | <username> |
| password | <password> |
Then I receive an error message: "<error message>".
Examples:
| username | password | error message |
| test | invalid | Invalid login |
| test | | Please enter the password |
| | invalid | Please enter the username |
Advantages of Using Scenario Outlines
Scenario outlines can be interpreted as a “template” of a test case. What they really do, once implemented inside a test automation framework, is execute the same scenario with different sets of data.
The advantage is that there are fewer lines of Gherkin and less repetition. This means that each time a change is needed in the common scenario, it can only be changed once and the change will be applied to all test data combinations.
Another upside of scenario outlines is that they can provide increased coverage with minimal work. To add a new test, you need to add a new example line.
Best Practices for Writing Scenario Outlines
- Incorporate real data: The team is less likely to overlook edge circumstances or hidden information when it employs real-time use cases to comprehend behavior.
- Communicate the objective using business terminology to help the team's non-technical and technical stakeholders understand each other better.
- Explain your intention rather than how it will be implemented; the step explanations should be minimally technical. Those should focus more on the functions of the system than on its operation
- Only keep what's necessary: To keep the scenario engaging for all participants, don't overcrowd it with unnecessary steps.
Takeaways
Enhancing Collaboration: BDD enhances collaboration between stakeholders and developers.
Simple Language: BDD uses a simple, domain-specific language to describe system behavior.
Agile Practice: BDD is a practice within agile software development.
Stakeholder Involvement: BDD involves stakeholders in defining system behavior.
System Behavior Description: BDD focuses on describing system behavior effectively.
Cucumber is a great collaboration tool between non-technical people, developers, and testers. It is a BDD tool that provides written specifications and can be used in testing. Multiple scenarios can be written to demonstrate various requirements.
It is a good idea to use scenario outline with distinct sets of values provided through the examples table when there are situations when the scenarios have the same steps but require different data values as inputs or outputs.
Subscribe to The CTO Club's newsletter for more insights.
