BDD User Stories and Scenarios !

Behavior Driven Development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria and art of writing scenarios.

The structure of a story

BDD provides a structure for a story. This is not mandatory – you can use a different story format and still be doing BDD – but I am presenting it here because it has been proven to work on many projects of all shapes and sizes. At the very least, your story should contain all of the elements described in the template. The story template looks like this:

Title (one line describing the story)

Narrative:

As a [role]

I want [feature]

So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title

Given [context]

And [some more context]...

When  [event]

Then  [outcome]

And [another outcome]...

Scenario 2: ...

Imperative vs Declarative Scenarios in User Stories

In my opinion, both styles have benefits and should be used appropriately based on the situation. The majority of examples on rspec's story runner currently on the web, are of the imperative type. Since the declarative type has many advantages I thought it would be worth while to present some examples and contrast the differences between the two styles.

Let’s look at the example: in Imperative Style

Story: User Registration

Feature: 

  As a User 

  I want to create a new user registeration to the site

  So that I can share my profile with the community

  Scenario: successful submission

  Given I'm on the user creation page

  When I fill in Name with ‘Manish’

  And select Gender as ‘Male’

  And fill in Username with 'agile_manish'

  And fill in Password with 'mypassword123'

  And Select in Occupation with 'Private Job'

  And check Terms and Conditions

  And click the Create button

  Then I should see the notice 'Thank you for your submission!'

  And the page should include the user name, gender, username, occupation

The imperative style uses highly reusable granular steps which outlines much of the user interface. This binds the scenario to that interface and requires more design decisions made up front. The step matchers for these granular steps are very easy to write. Once these steps are in place you can write the majority of your scenarios in this fashion without having to write custom step matchers. Due to the granularity of the scenarios however they become very brittle as they are subject to requirement changes from the customer. If a new field is added, for example, you must update the scenario to reflect this even though the underlying goal of the scenario has not changed.

Lets rewrite the above example in a more declarative fashion. The story narrative and scenario title will remain the same in Declarative Style

  Story: User Registeration

  Feature: 

  As a User

  I want to create a new user registeration to the site

  So that I can share my profile with the community

  Scenario: successful submission

  Given I'm on the user creation page

  When I add a new user

  Then I should see the page for my newly created profile

  And the notice 'Thank you for your submission!'

This style is more aligned with User Stories in the agile sense having more of the "token for conversation" feel to it. The first thing that you should observe about this style is how much smaller it is than the imperative one. This is a good thing. The imperative style tends to produce noisy scenarios that drown out the signal. With the declarative style the goal of the scenario remains clear. When a new field is added to the form the scenario does not have to be modified. Yes, you will have to modify the underlying step matcher but the scenario does not have to suffer dilution due to the change. The trade off is, of course, that you will now be writing step matchers for all of your scenarios.

Choosing Which Style To Use

I have made a strong case for the declarative style of writing scenarios. It would seem that one should never write a scenario imperatively based solely on the merits of maintenance and communicating story intent. While I think the declarative style has much strength it is not the best choice for all situations. The imperative style should not be discounted entirely because when used judiciously in the right scenario it can highlight certain aspects of the functionality and improve communication. It is also important to realize that the two types are not mutually exclusive. The styles can be mixed throughout an app, a story, and even an individual scenario to provide the appropriate level of granularity as the situation demands.