This post is to detail some basic strategies to keep test code DRY (Do not Repeat Yourself) in order to reduce code duplication & ensure that code is easy to maintain. Additional notes are provided to ensure that feature files can contain readable steps, without needing to create unnecessary step definitions to drive them.
The code examples are provided for Cucumber/Gherkin with Ruby.
Use Arguments in feature files & step definitions
Make use of arguments in order to reduce duplication of code in step definitions.
As per the code block below, arguments can be marked by use of quotation marks:
When I select "Shows" from the left menu
When I select "Statistics" from the left menu
Then I select "Movies" from the left menu
Then I select "Settings" from the left menu
The 4 test steps above can be handled by a single step definition that makes use of regular expression to match to any given argument. Be sure to provide a meaningful name to the variable that is relevant for all scenarios for easy test maintenance.
When(/^I select "([^"]*)" from the left menu$/) do |menu_item|
Improve step readability by matching step definitions to multiple keywords in a feature file
Using this approach, nothing in particular needs to be handled in the feature file.
Given I am at the Home screen
Make use of parenthesis and pipe to handle multiple keywords in the step definitions:
Given(/^(?:I|They) (?:are|am) at the Home screen$/) do
This technique can also be used to handle verification of boolean conditions, such as:
Modify the regular expression to match to part of a step, to allow for more natural language
Step definitions normally use ^$ to match to the full test step in the feature file (as above).
But as recommended by Cory Shires, in some instances, it can allow for more expressive language in your test steps if you match your step definition to only the beginning of a test step. Eg,
Can match to both:
In this case, anything after seconds, is written in the test step for readability only.
Make use of compounded test steps
If you find yourself repeating your test steps in your feature files for common processes, you can reduce the ‘noise’ by compounding the test steps in the step definitions.
For example, when I find myself constantly repeating the steps below:
Then I can write this as a compounded step in my feature file:
And I can specify that the matching step definition contains the sub steps, as follows:
Specification by design