This is the second post about Cucumber, where we’ll be exploring the creation of a feature. Cucumber centers on testing the expected behavior of your application, rather than the expected behavior of a method. I had someone explain to me once, “unit tests/specs are the methods/implementation you wish you had, Cucumber tests are the application you wish you had.”
User Stories
When thinking about a Cucumber feature you will want to relate it to a user story. If you’re familiar with Agile development stories are nothing new. For those who are not though it’s not too complicated. A story is simply an expression of value generally in the form of: ”As {a role} I want/need {to do some function} so that {business value}.” Generally the business value is best expressed in terms of: revenue generation, revenue protection, operational efficiency (cost savings).
For the example we’ll be using this story:
As a workshop co-ordinator I need to manage contact information so I can easily reference individuals and start communications with them.
You’ll notice that this story doesn’t imply implementation. You generally never want to imply implementation in a story. Also you’ll notice that the story is simple and comprehensible by pretty much anyone (business user, developer, average Joe Public).
Starting a Feature File
In our Rails application we’ll want to go inside our /features folder. Create a new file called manage_contact.feature. At the top of the file type in the following:
Feature: Manage Contact In order to easily reference individuals and start communications with them As a workshop co-ordinator I want to manage contact information
Now we have our first feature. The next step is to define some scenarios. Scenarios express various actions the user might take in relation to the feature. Below are some of the scenarios we came up with for this feature (these go below your feature entry – indented to be even to the “In order, As a, I want” section). You don’t need to, but I like listing the scenarios in order of priority, this way a developer working on the feature can just start on top and work downwards:
Scenario: View list of contacts Scenario: Add a new contact Scenario: Email a contact from the list Scenario: Remove an existing contact Scenario: Update an existing contact Scenario: Start an IM conversation with a contact from the list
Your finished feature file should look something like this gist. In the next post we’ll start to look at building out our scenario’s with step definitions, that is define what behavior we expect to happen with each scenario we have defined.
