We consistently share insights into our feature testing approaches and the tools we employ for the feature testing. Effective practices for acceptance tests emphasizes early consideration of testing in the quality process within our agile team, employing Cucumber.
Many have embraced Cucumber for formulating acceptance tests, implementing specific practices to uphold the standard of test code, and facilitating its reusability. We have outlined some of these practices to guide you in optimizing the utilization of this tool.
1. Use Background and be DRY while Using Cucumber
In Gherkin, the focus is on creating scenarios. However, there might be instances where steps are inadvertently repeated across various scenarios within a feature. The discovery of the reserved Gherkin term “Background” offers a solution. By using a context, we could include steps that are common to all scenarios, mitigating redundancies and simplifying adjustments with feature changes.
Example Without Background:@create_users @javascript
Feature:
Create new users
In order to create new users
As an App user
I want to have access to the App
Scenario:
Show a success message when creating a user with all information filled
Given I have logged in
And I have access to the Create Users App
And I am on the create a new user page
And I insert all user information
When I click on the save button
Then, I should see a success message.
Example With Background:
@create_users @javascript
Feature:
Create new users
In order to create new users
As an App user
I want to have access to the App
Background:
Given I have logged in
And I have access to the Create Users App
Scenario:
Show a success message when creating a user with all information filled
And I am on the create a new user page
And I insert all user information
When I click on the save button
Then I should see a success message
Scenario:
Show an error message when trying to create a user without an email
And I am on create a new user page
When I do not fill the email
And I insert all of other user information
And I click on save button
Then I should see an error message
Yes, according to the code, the Background is a Rspec Before type. If Before hooks and Background exist in your test before the hooks run first.
If your test contains both Before hooks and Background, the Before hooks will execute first.
2. Learn more about Scenario Outline
Take a look at this scenario:
Scenario:
Show a sum result when I execute a sum operation
Given I am on the calculator
When I press the number 4
And I press the number
And I choose the sum operation
Then I should see the 6 as result
Scenario:
Show a subtraction result when I execute a subtraction operation
Given I am on the calculator
When I press the number 4
And I press the number 2
And I choose the subtraction operation
Then I should see the 2 as result
Scenario:
Show a multiplication result when I execute a multiplication operation
Given I am on the calculator
When I press the number 4
And I press the number 2
And I choose the multiplication operation
Then I should see the 8 as result
Scenario:
Show a divide result when I execute a divide operation
Given I am on the calculator
When I press the number 4
And I press the number 2
And I choose the divide operation
Then I should see the 2 as result
Looking at the scenario above, you will see that all four of the generated scenarios essentially follow the same steps and have the same validation for the outcome. Additionally, consider that you now wish to create scenarios for additional calculator operations. Looks nothing like it, does it? Since it does not scale and makes maintenance difficult.
Cucumber provides us with an approach to arrange these scenarios and maintain them as scenario outlines or scenery schemes if you prefer.
Using Scenario Outlines, you make an example table with a scenario represented by each row. Referring back to the four scenarios that were previously shown, it would be as though you had created variables and used them on the table for the values that changed in each scenario. Stays like this:
Scenario:
Show the right result when I execute an operation on a calculator
Given I am on the calculator
When I press the number <number_one>
And I press the number <number_two>
And I choose the <operation> operation
Then I should see the <result> as the result
Examples:
| number_one | number_two | operation | result |
| 4 | 2 | sum | 6 |
| 4 | 2 | subtraction | 2 |
| 4 | 2 | multiplication | 8 |
| 4 | 2 | divide | 2 |The written variables are shown in the table’s first row as <variable> when you use them in the scenario. The subsequent lines show examples of how to run the tests and what the expected outcomes should be.
Have you noticed how simple it is to create and update scenarios? Moreover, it is easier to understand.
3. Write more declarative and less imperative scenarios
Hugo Baraúna claims that Cucumber is more of a documentation tool than a test automation tool in his book Cucumber and Rspec. Furthermore, our main objective should be clarity when writing acceptance tests in Gherkin.
The majority of the available tips are, therefore, always meant to make it simpler to understand what we transpose in our Gherkin file. The next one concerns the applicability that we assign to steps that contain a lot of superfluous details in certain scenarios.
We refer to these scenarios as imperatives because they specify the behavior that the scenario ought to exhibit rather than just what it desires. For example:
Scenario:
Show a success message when creating a new user
Given I am on the Create Users App
When I click on the “Create” button
And I fill in the “Name” field with “user 1”
And I fill in the “Email” field with “[email protected]”
And I fill in the “Password” field with “password”
And I fill in the “Phone” field with “123456”
And I fill in the “City” field with “City”
And I fill in the “Country” field with “My country”
And I click on the “Submit” button
Then I should see “User saved”
Take note that the person reading this scenario is not interested in several of the lengthy and detailed steps. Numerous fields, including name, email, password, phone, city, and country, can divert attention away from the most important thing, which is the successful creation of a new user at the base.
After reworking the Gherkin, we would have something like this, referred to as a declarative scenario, which clarifies what is truly valid so that readers can better understand what is being validated:
Scenario:
Show a success message when creating a new user
Given I am on the Create Users App
When I fill user information
And I click on submit button
Then I should see “User saved”
It is possible that you have noticed that the user’s name, email address, phone number, and other details have been removed, making it more obvious what our scenario is actually trying to verify. By changing only the implementation in the steps’ definitions and not the file.feature or the description of the steps’ definitions, we can scale when a change occurs in a particular field of the screen.
Everything is well with our scenarios, and we already know that it is best to leave the tests more declarative so that readers of the documentation you produced can understand what is meant to be tested and what needs to be validated.
But in the following situation, we need to exercise caution:
Scenario:
Show success message when creating a new user
Given I have logged in
When I fill in all the information
Then I should see a message
This scenario lacks business rules and is very generic; as a result, it cannot be used for automation or documentation. It also does not provide many hints about what will be validated.
4. Make use of “And” and “But”
Many have come across multiple instances of people repeatedly using the reserved terms Given, When, and Then in their exam answers. Although it can get very confusing and incoherent for anyone who reads the scenario, it is not incorrect to repeat it.
Take a look at this example:
Scenario:
Show an error message when trying to create a user without an email
Given I have logged in
Given I have access to the Create Users App
Given I am on create a new user page
When I do not fill the email
When I insert all of other user information
When I click on the save button
Then I should see an error message
Given that the terms “Given” and “When” appear multiple times in the test, it would be simple to substitute “And” for them in the example above.
Scenario:
Show an error message when trying to create a user without an email
Given I have logged in
And I have access to the Create Users App
And I am on create a new user page
When I do not fill the email
And I insert all of other user information
And I click on save button
Then I should see an error message
The “And” and “But” that you are going to modify will exhibit the same repeated “Given” and “When” behavior. You will notice that although the descriptions of their functions are more readable and understandable, they will still have the same names when you convert them to step definitions.
5. Consider Using Tags
Now, imagine that you have multiple scenarios with different features that are so well specified that you cannot tell, when you run the tests on the Cucumber terminal, whether the delay was due to a particular test running slowly or whether an uncoded test was able to cause your entire test suite to fail.
It seems difficult to solve, but it’s not when you start using the tags that Cucumber gives you. To use a tag, you create a word that means something about the context you want to differentiate from other scenarios and prefix that word with one @by adding it before the reserved words Feature and Scenario Like this:
@create_users @wip
Feature: Create new users
In order to create new users
As an App user
I want to have access to the App
Background:
Given I have logged in
And I have access to the Create Users App
@basic_user
Scenario:
Show success message when creating a user with all information filled
And I am on create a new user page
And I insert all of the user information
When I click on the save button
Then I should see a success message
Explaining the tags I’ve added:
The feature that is described is denoted by @create_users, which means that all tests are connected to the process of creating users on the system, and all of them will inherit this tag. Here in the QAs chapter, the tag @wipindicates “work in progress” and helps us avoid running tests that are not yet ready because they could break the entire test suite.
The last tag, @basic_user, was added specifically for the scenario in which the user pre-condition is logged into the system profile. This profile has limited privileges, but it is required in order for the scenario to be performed. You can also
annotate scenario outlines and their examples with tags.
Conclusion
All I have said is that these are the best practices, advice, and suggestions that we at Digital Results follow to assist you in creating documentation that is more coherent and readable. I have divided this post into two sections because while some of the advice is highly pertinent, not all of it is. In addition to the advice I provided on writing Gherkin, you will discover more about writing better Steps, Definitions and how to utilize them in the upcoming section.
Do you write your acceptance tests with Cucumber? Which of the above advice have you applied? Tell me in the comments below.
FAQS
How can I optimize my Cucumber test suite for efficiency in 2024?
To enhance efficiency, consider organizing your feature files logically, employing parallel execution, and utilizing scenario outlines to minimize redundancy.
What strategies can I implement to improve maintainability in Cucumber scenarios?
Adopt a modular approach by creating reusable step definitions, maintain clear and concise feature files, and regularly refactor your codebase to eliminate redundancy and enhance readability.
Are there recommended practices for effective collaboration in Cucumber projects?
Foster collaboration by establishing a common language through clear Gherkin syntax, regularly communicating with team members to align on testing objectives, and leveraging version control systems for seamless collaboration.
How can I ensure robust and reliable Cucumber tests in 2024?
Prioritize the use of explicit and unique selectors, incorporate reliable waits to handle dynamic elements, and implement comprehensive error handling to enhance the stability of your Cucumber test scripts.
What is the significance of incorporating data-driven testing with Cucumber?
Utilize data-driven testing by employing scenario outlines and examples to test multiple input combinations, enhancing test coverage and ensuring the robustness of your Cucumber test suite in diverse scenarios.
