Keeping the code DRY and readable with cucumber and ruby

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.

Some of the information provided is based upon The Cucumber Book & Cucumber and Cheese. Refer to the Cucumber website, for all things Cucumber & Gherkin related!

Use Arguments in feature files & step definitions

Make use of arguments in order to reduce duplication of code in step definitions.

Feature file

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

Step definitions

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:

screen-shot-2016-10-10-at-12-01-46-pm

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,

screen-shot-2016-10-10-at-12-43-42-pm

Can match to both:

screen-shot-2016-10-10-at-12-44-40-pm

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:

screen-shot-2016-10-10-at-1-02-02-pm

Then I can write this as a compounded step in my feature file:

screen-shot-2016-10-10-at-1-05-39-pm

And I can specify that the matching step definition contains the sub steps, as follows:

screen-shot-2016-10-10-at-1-11-41-pm

Specification by design

Scenario Outline

TBC.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s