Cucumber Tool for Behavior-Driven Development in Testing
To adapt to rapid changes in the market, IT teams have increasingly been following agile methodologies in their development process.
This presents a challenge for the test team. It is difficult to manage test cases and test scripts which potentially change with monthly updates.
Curious to know more? Check out our post on reducing maintenance for automated tests.
That’s why finding a suitable testing method early on is key for agile software development to be successful.
Looking for an expert testing partner?
Using Cucumber for a Behavior-Driven Development Approach to Testing
Many agile teams apply a behavior-driven development (BDD) approach to testing using the Cucumber tool.
But what is Cucumber? And why is using Cucumber for behavior-driven development a good approach for agile projects?
What is Cucumber?
Cucumber is a tool for running automated acceptance tests written in a behavior-driven development style.
One of its main features is the ability to execute plain-text functional descriptions (written in the language Gherkin) as automated tests. For example:
Feature: Update password
Scenario: Admin user can update user password
Given I am in the HR system with an Admin account
When I update password of another user
Then I receive a message for updating password successfully
And user’s password is updated to the new password
Advantages of Using Cucumber with Behavior-Driven Development
This great feature has played a primary role in supporting a behavior-driven development approach.
Why? Let’s dive into some of the key advantages of cucumber for behavior-driven development. Cucumber allows you to:
- Write BDD tests in Ubiquitous language, a language structured around the domain model. This language can be used by all team members including developers, testers, BAs, etc.
- Build bridges between the technical and nontechnical members of a software team
- Allows users to interact directly with the developers’ code, but is still written in a language that business stakeholders can understand.
- Last but not least, Cucumber is an Automated Acceptance Test Tool which runs tests written in a behavior-driven development style.
Cucumber Tool helps to improve communication between technical and non-technical members in a project.
Let’s look at the following requirement and its automation tests:
As an Admin User,
I would like to change the password of other user’s accounts.
Feature: Update password
Scenario: Admin user can update user password
Given I am in the HR system with an Admin account
When I update password of another user
Then I receive a message for updating password successfully
And user’s password is updated to the new password
Automation test with TestNG:
@test
public void testAdminUserCanUpdateUserAccountPassword() {
// create users
User userAdmin = new User(UserRole.ADMIN, username, password);
User user = new User(UserRole.VIEWER, user_username, user_password);
// use Admin user to update another user password
String message = userAdmin.updatePassword(user, user_new_password);
// verify password changed
Assert.assertEquals(message, “Password changed successfully”);
Assert.assertEquals(user.getPassword(), user_new_password);
}
Automation test with Cucumber
Feature: Update password
Scenario: Admin user can update user password
Given I am in the HR system with an Admin account
When I update password of another user
Then I receive a message for updating password successfully
And user’s password is updated to the new password
Both automation test scripts work very well to execute the test automatically. However, do all testers in your team understand these tests? Can business analysts and other stakeholders re-use these tests at an Acceptance Testing (AT) level?
Automation tests with TestNG is definitely too technical for most manual testers and BAs, and to re-use it. For AT is almost impossible; therefore, it is not a good approach.
Automation tests with Cucumber, on the other hand, is written in business domain language or in natural language, which is easily understood by all members of a software project team.
Communication is an important part of any development team, especially agile teams.
See developers and test often spend a lot of time discussing or disagreeing about the correct behavior of a specific feature.
With Cucumber Tools, the same feature specification is now used for development by developers and for testing by testers.
This minimizes the chance for misunderstandings or miscommunication.
Cucumber is an Automated Acceptance Test Tool
This means the development team AND BAs and product managers benefit when performing Acceptance tests automatically.
Acceptance Testing is generally performed at the product manager level to ensure that the development team has built the right feature.
Typical activities in this testing level include verifying the system against the original requirement with specific, real data may have in production.
Cucumber testing not only uses the requirements as its test scenarios but also allows BAs or product managers to change test data easily.
For example:
As an Admin User,
I would like to change the password of other user’s accounts.
Feature: Update password
Scenario: Admin user can update user password
Given I am in the HR system with an Admin account
When I update password of another user
Then I receive a message for updating password successfully
And user’s password is updated to the new password
Automation test with Cucumber:
Scenario Outline: Verify Updating user password feature
Given I am in the HR system with “<account_type>” account
and there is another user with “<old_password>” password
When I update password of the user to “<new_password>”
Then I got the message “<message>”
and the user password should be “<final_password>”
Examples:
|account_type |old_password |new_password |message |final_password |
|
|Admin |$Test123 |@Test123 |Password changed..|@Test123 |
|Viewer |$Test123 |@Test123 |Invalid right access.. |$Test123 |
Improving communication and supporting automated Acceptance Tests are distinguishable features of Cucumber.
The tool is also a great resource for testing teams. In most teams, there are always some testers with the programming ability for automated testing. But there are other manual testers with limited programming skills.
With the Cucumber tool, all testers at different skill levels can participate in making Automation tests.
In the example mentioned above:
- Any tester understanding the business logic and workflow can write feature files, add more scenarios, as well as test datasets.
- Any tester with a basic knowledge of programming (able to create objects, to access properties, to call method, etc) can create step definitions.
- Any tester with more advanced programming skills can join the process of making the framework, define the data source connection, and so on.
Challenges of Cucumber
However, there are a few challenges when using Cucumber
- Cucumber supports running test scenarios that specify in a plain text file using domain business knowledge. Hence, any chances of misunderstanding can be avoided. The test scenarios should be expressed clearly, and its implementation must be performed exactly for each step.
For example, when we want to verify Searching feature on Google, the test should be:
Scenario: performing search on google
Given I am on “www.google.com” site
When I search for “Cucumber and BDD”
Then …
Some people may combine steps together to have following test:
Scenario: performing search on google
When I search for “Cucumber and BDD”
Then …
Both scripts are correct but the latter is not clear since it does more than what is expected.
Imagine if we want to extend the test to search with more text. The steps will be difficult to re-used. By not strictly folliwing this rule, it will be difficult to maintain when extended.
- Cucumber steps are expressed in natural languages, and they can be re-used in different test scenarios. It maximizes the re-use but keeping the test readable is a big challenge. If the test is written at a very high level so that any stakeholders can understand; few of steps (bold) can be reused:
Feature: Update password
Scenario: Admin user can update user password
Given I am in the HR system with an Admin account
When I update password of another user
Then I receive a message for updating password successfully
And user’s password is updated to the new password
Scenario: Viewer user cannot update user password
Given I am in the HR system with a Viewer account
When I update password of another user
Then I receive a message for not able to update user password
And user’s password remains the same
On the other hand, if the test is generic and can be re-used, i.e. verifying updating user’s Last Name, non-technical stakeholders will find it difficult to understand and do Acceptance Tests as we expected:
Scenario: Admin user can update user password:
Given I am in the “$System.HR_Page” with “admin@test.com” username
and “$Test123” password
and there is another user in “$System.HR_Page” with “user@test.com”
username and “$Test123” password
When I update “$UserTemplate.Password” of “user@test.com” user to“@Test123”
and I save the response message as “response_message”
Then “$response_message” should be “Password changed successfully”
and the “user@test.com” user’s “$UserTemplate.Password” should be“@Test123”
In my testing project, my way on writing feature files, test scenarios moved between very generic and very specific all the time until it gets the acceptable balance:
Scenario: Verify Updating user password feature
Given I am in the HR system with “Admin” account
and there is another user with “$Test123” password
When I update password of the user to “@Test123”
Then I got the message “Password changed successfully”
and the user password should be “@Test123”
Or with some more test data:
Scenario Outline: Verify Updating user password feature
Given I am in the HR system with “<account_type>” account
and there is another user with “<old_password>” password
When I update password of the user to “<new_password>”
Then I got the message “<message>”
and the user password should be “<final_password>”
Examples:
|account_type |old_password |new_password |message |final_password |
|Admin |$Test123 |@Test123 |Password changed..|@Test123 |
|Viewer |$Test123 |@Test123 |Invalid right access.. |$Test123 |
Things to Keep in Mind When Testing with Cucumber
There are some key points for a testing team who wants to start with Cucumber:
- Consider automation tests as important as a real project. The code should be follow coding practice, convention, etc.
- A good editor should be considered. The editor should support debugging and editing feature files in normal text format. Aptana (free editor) and RubyMine (commercial editor) are highly recommended.
- Scenarios should be expressed as a Behavior under verifying.
- Last but not least, make feature files a real “communication” layer, which is a place for receiving test data, formatting test data. No domain business logic is included.
By supporting a communication layer on top of a strong testing framework, Cucumber not only can be used to perform automation test on a wide range of testing fields, from backend to frontend, but it also helps to improve the communication among members in team.
This feature is hardly found in other testing frameworks.
With my experience building Automation test with Cucumber tools for testing Web services and Web UI, this approach is highly recommended for an Agile software project.
Its stability helps my team reduce significant testing effort on regression tests.
Looking for a team to help with your software development or testing project?
