Behavior Driven Development and Cucumber, embracing agile development

Behavior Driven Development has become a key tool in our toolkit as developers strive to become leaner and more agile. Here at Boost we have been using Cucumber with Ruby on Rails to integrate Behavior Driven Development into our everyday software engineering practices.

At Boost we’ve been using Test Driven Development (TDD) for some time now. Test driven development is a process whereby the developer writes an automated test prior to the beginning of coding of a new function or improvement to an existing function – the test fails at the outset as no code has been written. The developer then develops the code to pass the test, as well as refactoring the code to an accepted standard.

We’re also using Behavior Driven Development (often referred to as BDD). Behavior Driven Development extends Test driven development by writing text cases in a way anyone can understand. Behavior Driven Development fits in well with Scrum in that the Behavior Driven Development tests can be written by the product owner. A product owner writes acceptance criteria for a user story within a sprint, but by asking the product owner to contribute to Behavior Driven Development testing by writing feature descriptions we are fostering collaboration rather than merely co-operation. The product owner is able to take fuller responsibility for a successful outcome.

Over the last year we’ve been using a tool that combines both Test Driven Development and Behavior Driven Development. Cucumber is a tool that enables the product owner and developer to work together to produce features. Here’s how it works:

1. The product owner writes a plain text description of a task and how it should work using a particular syntax (Gherkin) and providing scenario examples. Here’s an example of a feature description written for our Intuition HQ site:

Feature: Sign up to a plan
Sign up should be quick and friendly.
Scenario: Successful sign up
Users should see a confirmation when their payment details have been accepted.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation page
Scenario: Invalid card number entered
Where an incorrect card number is entered
Given I have chosen to sign up
But I enter an invalid payment card number
Then I should be told that the card number is invalid
And the form should be redisplayed offering me the opportunity to re enter my card number

2. The developer writes corresponding step definitions. The step definitions should include the phrases used within the feature description. The step definitions are tests written in code that Cucumber then runs against the site. The first time the tests are run they will fail as no code has been written.

3. The developer writes code for the new functionality described in the feature description and re runs the tests. Cucumber highlights success within the feature description in green, pending in yellow and failure in red as shown in the image below:

5. The developer amends the code and reruns the tests and so on until Cucumber shows the entire feature in green indicating that the tests have been successful.

The advantage of working with Cucumber is that both Behavior Driven Development, (in the form of the feature descriptions and scenarios) and test-driven development, (in the form of step definitions), are used to verify the success of development.

I spoke to one of our developers about his experience of using Behavior Driven Development and his response was that one of the most important advantages of using Behavior Driven Development is that it allows the product owner to write acceptance criteria in the form of features. The developer can then work towards developing step definitions to test the features the product owner has defined. The step definitions correlate with the acceptance criteria/features with the intention of leaving no discrepancies between what the product owner wants from their product and what the programmer develops.

Behavior Driven Development is proving to be a valuable tool in helping us to eliminate the gap between developer and client understanding of requirements therefore producing successful and useful features.