While development strategies like pair programming or test-driven development are great for the actual coding that developers do, they don’t always capture the full picture of what the business or your users want. Behaviour-driven development (BDD) looks to solve this issue by framing development within the context of the business and the users, making sure that the coding you do does more than past coding tests and have great code coverage. What you develop also needs to meet the requirements of the business and your users.

In BDD, the business, developers and testers need to work together to make sure that the code does exactly what users want it to – in other words, it’s a user-centric approach. Another way of putting it would be 'Behaviour-driven development is about implementing an application by describing its behaviour from the perspective of its stakeholders'. So how does it work?

As you can see in the diagram, BDD is an iterative process that allows change. It begins with the definition of a requirement as a feature and the specification of the behaviours in terms of scenarios. This is written in a ubiquitous language, like Gherkin, but is essentially a set of English sentences using a common set of keywords.

You can export each feature into a feature file where a developer can use it to link up to the software they’re developing. To do this, you write a specialist script called a step definition. The step definition references the features and scenarios described in the feature file and then hooks into the actual software that is being developed. Here, it performs relevant tests based on whatever the scenario requires.

Here's the strange bit. All of this happens before you’ve even written the software so, at first, all the tests fail. But as you write more of the code, more scenarios pass until, eventually, the whole story passes.

So BDD is reliant on living documentation, using a ubiquitous language that everyone involved can understand. Requirements are expressed as features, with acceptance criteria being expressed as scenarios or examples. Each scenario should provide an example of how the feature should work. As I mentioned earlier, Gherkin is a common language used to define features and scenarios, by phrasing them as 'Given'; 'When'; 'Then'.

Let’s look at an example of this in action. Say the customer requirement is something like ‘Books can be added to the shopping cart’. Gherkin would describe this as Given my shopping basket is empty... When I add the book 'BDD is Fun' to the basket... Then the shopping basket should contain one copy of 'BDD is Fun'.

You’ll often see scenarios written out using one of two styles: imperative or declarative.

Imperative is usually more prescriptive, longer, and more minutely detailed. It takes less for granted. This style forces developers working with the scenario to write link up code at a much lower level of granularity. This can be beneficial because it means the scenario writers can write many variations on the same scenarios to test different kinds of conditions. It's often also easier to work in new scenarios without a lot of extra development effort.

The declarative style is less prescriptive and allows the developers to write specific links to individual scenarios. This gives less flexibility to the scenario writer.

Ok so last up, let’s talk a little bit more about Cucumber and Gherkin. Cucumber is a tool that supports BDD. It does this by reading executable specifications written in plain text and validating that the software does what those specifications say. The specifications consist of multiple scenarios. Let’s look at an example. In Mastermind, our scenario is that the Breaker guesses a word. Given the Maker has chosen a word, When the Breaker makes a guess, Then the Maker is asked to score.

Each scenario is a list of steps for Cucumber to work through. Cucumber verifies that the software conforms with the specification and generates a report indicating success or failure for each scenario.

For Cucumber to understand the scenarios, they must follow some basic syntax rules called Gherkin. We’ve already been through what this should look like, and in the scenario, you can clearly see that we’ve used the proper Given, When, Then format.

That’s it for this video.

Behaviour driven development puts the user at the heart of the development process and helps us make sure that whatever we create actually does what the user wants it to. By using a ubiquitous syntax like Gherkin, we can use tools like Cucumber to validate that the features and scenarios that have been co-developed by the business, coders, and testers can be translated into code that delvers functionality for our users.