Most recent projects I have worked on have used unit tests to define the requirements of our code and ensure they are met. Typically the tests are written by the developer while they are coding the solution. However this means that the tests are based entirely on the developers understanding of the requirements, which may not always be the same as the stakeholders understanding.

To combat this issue we are introducing behaviour driven development, to agree on a set of requirements for each feature with the stakeholders before starting development. The requirements are captured using the Gherkin syntax (Given, When, Then) based on real world examples. These examples can then be wired up to the system directly as automated tests using Specflow.

OK, show me the example already

Here is a fictionalised scenario which demonstrates the value that BDD adds to a project. An abbreviated version of the initial scenarios drafted by the developer are as follows:

Feature: Process 3D secure authentication response
        As a logged in user
        I would like to place a 3D secure authenticated order
        so that I have assurance of the websites security

Scenario: Handle a 3D secure response of AUTHORISED
    Given a 3D secure response of AUTHORISED
        When  i view the order confirmation page
        Then  the order status will be Complete

Scenario: Handle a 3D secure response of NOT AUTHORISED
    Given a 3D secure response of NOT AUTHORISED
        When  i view the order confirmation page
        Then  the order status will be Cancelled

Scenario: Handle a 3D response of NOT PROCESSED
    Given a 3D secure response of NOT PROCESSED
        When  i view the order confirmation page
        Then  the order status will be Cancelled

Evolving the scenario

The assumptions shown in these scenarios are perfectly reasonable, an order will only be completed if the 3D secure security check returns an authorised response. However it should really be a decision for the stakeholder’s business whether the system should behave in this way. There are several valid scenarios where all 3D responses should actually result in a completed order, for example:

Scenario: Handle a 3D secure response of NOT AUTHORISED
Given a 3D secure response of NOT AUTHORISED
And a total order value order value under the following amount:   25
When  i view the order confirmation page
Then  the order status will be Complete

The stakeholders calculated that the risk of charge-backs was so low on orders under 25 that they could disregard the 3D secure response completely and allow ‘not authorised’ transactions to be completed.

Here we can see a clear benefit in the stakeholder sharing their understanding of the system requirements with the implementation team. Rules which are beneficial to their business can be incorporated into the system, resulting in a more effective solution from the outset.

If you are interested in reading more about using BDD for web applications I can recommend Steven Sanderson’s excellent blog post.