Cucumber is an awesome tool that can help your team create living documentation for your applications. It is a great way to gain a better understanding of how your application should function. It utilizes Gherkin – a language that is at the core of Cucumber’s ability to both document and automate tests. It allows for writing tests around how a feature should behave – a process known as Behaviour Driven Development. Gherkin focuses on 3 core elements: an established condition, an action, and an expected result. When writing features, it can be difficult finding the best way to implement what you need.
High Level
Think about an overview of the desired behavior of a particular feature. Cucumber – and BDD – really shines in its ability to provide living documentation that is easy to read and understand. It allows for each team to gain a better understanding of what is being tested and how a feature should function – something that is along the same lines as writing user stories.
Here is an example of a simple feature that uses declarative language:
Feature: Add Profile Avatar
In order to show what I look like for others
As a user
I want to be able to add an avatar picture to my profile
Scenario: User navigates to profile page
Given I am on the home page
When I log in
Then I should be directed to my profile page
With this example, the feature and scenario are simple to read and provide information on expected results. You can continue adding scenarios that are related to that feature in order to build out the suite and test coverage.
Your specific interactions with the UI would then go into your step definition files, leaving your features accessible for any member of the team. A problem that can pop up with this, though, is the potential of having duplicate steps or multiple variations of the exact same step. That’s important to keep in mind as the suite grows.
Low Level
A lower level view would move those interactions with the UI into your feature files. Here is an example:
Feature: Add Profile Avatar
In order to show what I look like to others
As a user
I want to be able to add an avatar picture to my profile
Scenario: User navigates to profile page
Given I am on the home page
When I fill in “Username” with “Test”
And I fill in “Password” with “123”
And I click on the “Login” button
Then I should see “This is your profile page”
And I should see the “Log out” button
The exact same workflow is described, but this way of writing features incorporates the specific steps that are needed to achieve the desired result. Now, there is some benefit to this approach. This is more reminiscent of Test Driven Development, as you can see exactly what is being tested right within the feature and what steps make up the functionality. It can make troubleshooting failures a lot easier, especially if the steps in the features match the steps your QA and UAT teams follow for manual testing. That’s actually a great way to stay in sync with app behavior and what needs to be tested. This can work well if your scenarios are small enough.
There are some definite pitfalls to this way of writing feature files and they can hit you pretty quickly. If a scenario requires a lot of steps for execution then your feature files can become pretty overwhelming. Downright ugly, even. The problem with that is it limits who can read these features – which is a core purpose of Cucumber itself.
Both approaches work well depending on the need. A system of reusable steps can make writing tests quick and efficient. An excellent example of this can be found here – a test harness for spinning up tests quickly. The idea with this harness is to develop template steps that can fit into any scenario needed – something pretty important if you want to avoid cumbersome files.
Cucumber is pretty flexible and allows for a variation of approaches for writing feature files that work best for your team. The important thing to consider is writing features that are scalable and easily accessible for each team member. Feature and step definition files can become unwieldy pretty quickly if you’re not careful. It’s best to define what is needed for the team and use Cucumber to meet those needs. Either way, it gives great insight into the behavior of your application, providing there is a good balance in writing your features.
Want to learn more about Cucumber? Check out their blog for podcasts, events, and more tips.
*image courtesy of cucumber.io
