Behaviour Driven Design Encourages Shared Understanding
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.