When we we get a request to write some software, it usually comes in the form of a list of features and expectations of what the software will do. It’s not written in a technical language, or computer code or even detailed enough to covert into a unit test. It’s usually something like “When I tap this button, I want to change the colour to red”.

As developers, we can take this expression and convert it into lines of computer code, often hundreds of lines. We can then write unit tests which verify that the code successfully works. But showing the results of hundreds of unit tests to the customer usually means little to them. It’s at a too finer detail and often bears little resemblence to the high level features they requested. As the developer it can also be hard to be certain that we have not missed something at the big picture level.

Behavioural Driven Development provides a framework for matching the simplicity of the customers requests against an actual running application and reporting back what is working and what is not. From the developers point of view, it validates that they are not missing anything at the higher level their unit tests may have missed.

The essence of the idea is this, the customer and developer work together to write the features and expectation in a very English language like style that they both can understand. This is usually called a Domain Specific language (DSL) and directly relates to the application being built. These descriptions of what the application will do are called Stories with each individual story expressing one particular feature. Here’s a typical example:

As the user of the application
given the application has been started
when I tap the "About" button
then the application shows me the "About" screen

Once a basic set of stories has been developed, the developer can use them to drive the development of the code. To do this, the developer uses a software tool or framework that can read the files containing the stories and relate them directly to code that interacts with the application. Initially, as the application has not been written, the framework would report that it fails to successfully execute all the stories. But as development goes on, more and more of the stories will be executed successfully. This provides a very good mechanism for a customer to understand the progress of the development.

The up shot of all of this is the by using a BDD framework it becomes much easier to express the customers goals, to match them with test code, and to be able to show the customer that those goals are being met as the development progresses.

Index

Download latest
static library
v0.2.0