How?

There are two parts to BDD adoption for teams.

• Mindset
• Tooling support

The team definitely needs to buy-in to the practices and benefits of this development methodology.

And then there are tools that help you facilitate BDD adoption. These tools basically propose a structure for writing specifications that brings in the needed clarity into business requirements.

A very commonly used structure is that of the user story in agile teams.

The user story requires you to define every piece of requirement in terms of :

• who is the primary stakeholder for a particular requirement
• what effect does the user wants from this requirement
• what business value would the user get if the aforesaid requirement is acheived.

Consider the addition example to understand the above.

As a user of the calculator program
I want to have an addition method supported in the program
So that I can add two numbers

Further, BDD expects the desired behavior to be written in a Given, When, Then format.

• Given describes the pre-requisites for the expectation
• When describes the actual steps to carry on the effect of the expectation
• Then describes the verification that the expectations were met.

e.g. Consider the following expectations

Should allow addition of two positive numbers

Given the calculator has an addition program
When i choose to add 2 numbers
And i add 2 and 2
Then the result is 4

Now there are testing tools that help to automate and execute scenarios like above. So these specifications can actually serve as living documentation. If a requirement changes, the test has to change for it to execute successfully.

This book is going to talk about one such tool, Cucumber and the whole test framework ecosystem around it.