Revisiting Cucumber - Feature File

​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.