Test automation continues to be a key driver to successful enterprise software deployments. This week’s post dives into Cucumber, a test automation tool that enables behavior-driven software engineering and test models.
There has historically been a gap between software requirements and how humans actually use software. This causes deployment problems, rework, and unexpected quality issues. As companies move from reactive QA toward proactive and predictive QA, new paradigms are needed.
Origin of the Cucumber Test Automation Tool
To get rid of the ambiguity and make everything connect the entire software development lifecycle, the development process needed something that bridges the customer’s acceptance criteria to the actual development and testing process.
So the idea was to enhance the existing TDD (Test-Driven Development) process and combine the following acceptance tests, functional requirements and software documentation into one format that would be understandable by non-technical people as well as test automation tools.
Check out our article on How to Determine Cost of Poor Quality in Software Engineering >
Introduction to Cucumber
Like other test automation tools you can’t just download the cucumber and start coding and automating your test cases there are certain process and steps that need to be followed to make full usage of the cucumber and that process is known as BDD Behavior-Driven Development.
In this process there are three main people involved the person who is dictating the requirement it can be Business Analyst or a product owner, the person who is going to design implement and develop it -Developer, and the person who is going to test and certify it.
This group of people sit and discuss the feature that has to be implemented and discuss different use cases and how the system has to behave at different point of time in different situations. And these behaviours are noted down as scenarios which becomes the written document of how the system has to behave/react in different scenario.
The above diagram roughly depicts how a typical BDD process looks in short
Language or Platform Supportability
Cucumber implementation: is available in major open source languages like Ruby,Java,Python,PHP and also on proprietary platforms likes .NET
Framework Integration: Cucumber is integrated and supported with following frameworks like Ruby on Rails, Selenium, Waitr, Capybara, etc…
Click here for downloads .
Note** before jumping into the implementation and other features of Cucumber this is only for those who strictly follow the process of BDD/TDD for others it may be bit complicated to implement and integrate into their existing test automation frameworks. In other words, cucumber should be used in all the places where the business has reason to have opinions about the behavior.
Components of the Cucumber:
1. Feature Files:
These are typical test case files in a BDD process and also act as living document to the business requirement and a bridge between the requirement documentation and implementation part of it.
The syntax/format in which these feature files are written is called as Gherkin ; this provides a set of rules which needs to be followed while composing your feature file. Your feature files will have an extension ‘.feature’.
Feature: This provides a high level understanding of what the enhancement or the user story is about and what all changes are going to be done as part of this enhancement and what is the expected output from this.
Scenario: The description following this keyword gives the intent of this test case or scenario. What is being verified in what conditions. To make a scenario more readable gherkin provides some keywords which you can also call as clauses.
Given: if you know the classical format of maintaining the test cases in a excel sheet. The statement beginning with Given clause represents the preconditions required for the particular scenario and if your scenario requires more than one precondition ‘AND’ clause can be used immediately after the given.
When: any statement that starts with this clause represents the steps-to-execute part of the test case document. It contains the executions steps that are particular to this scenario. Most of the times this part contains more than one step and hence along with this clause we also use the AND clause as well.
Then: any statement that starts with this clause represent the verification steps and expected result of the scenario. If this part also contains multiple steps then AND clause is used along with it.
See our article on How DevOps Improves Quality Assurance for Software Engineering >
Other Handy parts of the gherkin feature file:
Background: If any part of your whole feature file is needed to be executed before every scenario then those statements can be put with background clause or keyword.
Example:
Scenario Outline: When you have same steps to be executed with different set of data then gherkin allows you to specify your steps in the following format using another feature provided by gherkin called as DATATABLE. The below example illustrates how a scenario outline looks like
Scenario: eat 5 out of 12
Given there are 12 cucumbers
When I eat 5 cucumbers
Then I should have 7 cucumbers
Scenario: eat 5 out of 20
Given there are 20 cucumbers
When I eat 5 cucumbers
Then I should have 15 cucumbers
Instead of writing repetitive scenarios for different sets of data we will have same set of steps executed on different sets of data using datatable and scenario-outline concept.
Scenario Outline: eating
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
Datatables: gherkin allows you to pass multiple arguments in a steps but when the number of arguments that need to be passed to a step crosses more than two it is suggested to use Datatables and also using this not only allows to provide n number of inputs but also provides provision to pass multiple set of data to a single step and also makes your scenario more readable.
Consider the following scenario example:
Setting up your Java environment for cucumber execution:
- Intellij Community Edition – this is the IDE that we will use to write our feature files and all the code behind.
- JAVA – Get the latest jdk on your machine. At the time of writing this book, jdk 1.8 is the latest.
- Get the cucumber-jvm plugin
- Open Intellij
- Go to Preferences -> Plugins
- Choose to install Cucumber for JAVA plugin.
- You might need to restart the ID
- Create a new Maven test Project
- Add the following project dependencies to your POM.xml
<dependency> <groupId>info.cukes</groupId> <artifactId>cucumber-java</artifactId> <version>1.x.x</version> <scope>test</scope> </dependency> <dependency> <groupId>info.cukes</groupId> <artifactId>cucumber-jvm</artifactId> <version>1.x.x</version> <type>pom</type> </dependency> <dependency> <groupId>info.cukes</groupId> <artifactId>cucumber-junit</artifactId> <version>1.x.x</version> <scope>test</scope> </dependency>
Running your First test Scenario:
Below steps represent a scenario that is present in your feature file called NewEnhancement.feature
Feature:
As a user
I want to be able to add new clients in the system
So that i can add accounting data for that client
Scenario: Sign up a new user
Given the user is on landing page
When she chooses to sign up
And she provides the first name as Jenkins
And she provides the last name as Joe
And she provides the email as emailaddress@betsol.com
And she provides the password as password
And she provides the confirm password again as password
And she signs-up
Then she should be logged in to the application
The code representing the above steps in java is called the glue code and to match the steps against their respective glue code certain format of regular expression is used.
The same implies to the other statements irrespective of the clause/keyword used
Put the above represented code in .java file inside a class for example consider the file name as CucumberSteps.java.
Configuring your IDE to run the feature file
You cannot run your feature files directly after composing your feature file. You need to tell the jvm that this is your feature file which you want to execute and also specify the java file which contains all the stpe-definitions or glue code for the steps present inside the feature file
- Go to Edit configurations
- Provide values in the run configurations
- Go back to the feature file and right click and run as feature option needs to be selected.
Sources and References:
https://github.com/cucumber/cucumber/wiki/Gherkin
Conclusion
Successful software delivery hinges on the successful combination of people, process, an tools. If you’d like to look more into the tools we leverage to continue to push the test automation envelope, check out our article Getting Started with Sikuli for Test Automation.
[embedit snippet=”after-article-getresponse”]
Tags:
