`In my previous post, I discussed a little bit about feature files.  Let’s see what it takes to set up and run the feature file.  These instructions are geared towards *nix and mac os.  Reach out to me, if you would like set up instructions for windows.

First, you’ll need to have ruby and bundler installed.  Visit here to learn how to install Ruby for you system and then install bundler by running the command `gem install bundler`.

Now, let’s create a folder to store all our code.

> mkdir cucumber-example

Navigate to that directory
> cd cucumber-example

*Gemfile*

To begin, create a file called Gemfile with the following entries:

source 'https://rubygems.org'

gem "cucumber", "2.4.0"
gem "rspec-expectations"

Now, run the following command
>  bundle install

This will generate a Gemfile.lock file.

Next, we’ll create the feature folder and place the feature file in it:

> mkdir features

Next we will insert the following feature file in the features folder:

> vi features/folders.feature

Now, we run the following command:

> bundle exec cucumber

If all goes well, you should end up with the following:

You can implement step definitions for undefined steps with these snippets:

Given(/^I have a new job id to process$/) do
  pending # Write code here that turns the phrase above into concrete actions
end

 
You can implement step definitions for undefined steps with these snippets:

When(/^I read the list of job ids$/) do
  pending # Write code here that turns the phrase above into concrete actions
end

 
You can implement step definitions for undefined steps with these snippets:

Then(/^I should have a new folder named after the new job$/) do
  pending # Write code here that turns the phrase above into concrete actions
end
1 scenario (1 undefined)
3 steps (3 undefined)
0m0.091s

​Although I’ve been using Cucumber for a long time, it wasn’t until I started working at Macy’s that I really began using it.  Back then, it was a way for me to document my test cases and get automated integration tests in place.  It was easy when I worked on projects were I was the only QA engineer.  As I got integrated with the bigger projects, it was back to the traditional waterfall of development.

Because we were an enterprise company, best practices some times went out the door, because of code freezes and features had to get out the door by a particular date to meet some sale.  Everyone above my pay scale saw the value in cucumber, but modified it to meet their organization.  Still, we never achieved the intent that Cucumber brings to the table.

So, what value does Cucumber bring to the table?  First and foremost is the power of the feature file.  Written well, it can tell the whole team involved in the project what it is they are developing.  Here’s a simple feature file for a feature to generate folders that an application downstream will read from.  Upstream there is an application that will submit a new job id to be processed.

folders.feature

Feature:  As an application,
  I would like to have folders based on job ids,
  so that I can download daily reports to that folder.

Scenario:  I want to have a folder created named after the job id
  Given I have a new job id to process
  When I read the list of job ids
  Then I should have a new folder named after the new job

Scenario:  I want to have a subfolder with today’s date in the new job id folder
  When I have created a new job id folder
  Then I should have a new folder with today's date

Scenario:  I want to have a new date folder in an existing job id folder
  When I start a new day on my existing job
  Then I should have a new folder with the new date

The feature file is simple and straightforward.  You may wonder why there are no more than three steps  in each scenario.  The reasons for this is:

• Implementation may change throughout the development of this feature
• Reduces the need to update this file during development (leave that to the step definitions that define how we test the application)

For those unfamiliar with cucumber, here’s the breakdown of the keywords that are in bold.

Feature - High level description of the feature this file covers.  Over the years, I’ve become a fan of writing this section in the “As a/an …, I would…, So that…”.  This helps me to enforce ownership in the work I’m doing for this feature, whether as a product owner, developer, or tester (the three amigos).

Scenario - I equate this to an acceptance criteria.  It focuses only on one thing and that is the only thing I will test for this scenario to be accepted.  Just like the feature file, I tend to write my scenarios with “I want to …”

Given - Equivalent to a precondition step in a test case.  Not always required in every scenario.  In this case, because I plan to develop integration tests for this feature, the Given step will apply to all my scenarios.  There is a keyword called Background in cucumber, but I tend avoid using it for performance reasons.

When - Equivalent to the test step in a test case.

Then - Equivalent to the expected results in a test case

Notice that the Given/When/Then are followed by I.  This just continues the “ownership” concept that developing in cucumber brings.

Nouvola has a great video that best explains what I currently do today.