From writing the first lines of a cucumber test case to best practice tips, this post makes note of some techniques that can be used in any cucumber testing project.

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

Prerequisite: Test project is configured with cucumber installed. Please see guide to setting up test framework for Android, Appium, Cucumber, Ruby. 

Background

Cucumber is a tool that supports Behavioural Driven Development (BDD) practices. It provides the ability to specify a system’s behaviour in plain English text, making the test scripts human readable on the highest level of abstraction. Cucumber focuses on the end user experience, and the style of writing tests allows for reusability & scalability.

Cucumber / Ruby framework file structure

Note that there are Ruby gems which can create this file structure automatically. For reference purposes, the basic file structure that a cucumber/ruby project requires is:

Once the test project contains the basic file structure, if you execute: cucumber command at your test project’s root directory, you can verify that your cucumber project is configured correctly when output that includes the number of scenarios and steps is returned.

1st Cucumber Scenario

Inside the features folder, multiple .feature files can be created, grouped according to system features.

Using the Gherkin language, each test case can be written according to the syntax provided below. The words in pink font are reserved words in Cucumber/Gherkin.

The Feature represents features within the system under test.

The Scenario represents the requirement, such as a business rule. Effectively, these represent test cases.

The test case steps can be written using the Gherkin reserved words:

Given – the pre-requisite

When – the action

Then – the outcome

And & But – these reserved words are used to make the steps more readable.

The test case steps are later defined in step definition files, to enable the tests to interact with the system’s code base.

By separating the feature files and step definition files, the test cases remain human readable, and the step definitions (and page object files) become the go-to place for maintaining the test cases when the code base changes.

Note that the keyword (Given, When, Then, And, But) does not actually effect your test step. Example:

When I click on the home button

&

Then I click on the home button

These two steps operate exactly the same when the test is executed. The keyword is only used for human readability of the test steps, but is ignored when the test case is executed. So in this case, only one step definition is required.

Example of a completed Cucumber feature:

Generate Ruby step definition snippets

The next step to creating a cucumber test, is to define the steps of a feature, by associating them to the system under test’s code base, via the step definition files.

When the cucumber command is executed, 2 things will happen: 

1. test cases will be executed
2. step definition snippets will be created for any feature that does not have step definitions defined

To generate step definition snippets (without executing test cases), run:

cucumber –dry-run

The result will return snippets of code that can be copy/pasted into the corresponding step definition files. Example: 

See the automatically generated Ruby script!?

Define Ruby Step Definitions

Using the step definition snippets, enter Ruby code into the methods, in order to drive a test case.

Example: (Ruby commands to print information to log file have been added to the step definition file)

To execute the test case:

cucumber

And the result will be: 

Here, you can see the result of the print commands, along with the test case results and test execution time.

This demonstrates the basic concepts for Cucumber test creation. However, in order to drive a test against the code base for an Android/Appium/Cucumber project, we need to enter Ruby/Appium steps into the step definitions so that we can integrate with the code base.

Implement step definitions for Appium with Ruby

In order to interact with the Android native application code base (for SeriesGuide) application, using Appium, we need to enter step definitions that locate elements using the Appium locators & selenium commands. This information will be provided in a separate post. 

Keeping the Cucumber code DRY

Various techniques can be used in Cucumber to keep the code ‘DRY’ (Do Not Repeat Yourself!).
These techniques will be covered in a separate post.