Close

Behaviour Driven Development

Lately, I’ve had a lot of discussions with people about Behaviour Driven Development (BDD) and what it means to them. I have always taken something different away each time, including some things I feel are misconceptions.

BDD is not about testing in the traditional sense of the word; it does not replace the need for testing or a QA process, and it is not a set of tools that can be used as part of your test suite.

BDD is:

“a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.” – Dan North

Konstantin Kudryashov (@everzet), creator and maintainer of Behat, has given many talks on BDD, and I feel he provides a clear message and definition of what the actual practice is about. Here is my understanding of BDD based on those talks.

Communication & feedback

In a typical software development project you will have three ‘entities’ or ‘roles’: 

Client/Stakeholders
 
  • They come up with an idea for a project
  • They communicate this idea, in a business language which they understand, to the delivery team in the form of requirements

Delivery Team/Developers

  • They take the requirements from the client and translate them into a language that they can understand – this is usually some sort of programming language

Computer/Code

  • This interprets the developer’s programming language into something it can understand and process

Feedback is then given to the client in the form of working features, creating an opportunity for the client to talk to the delivery team. However, at each stage this communication can easily be misinterpreted by both the client and the delivery team (and in traditional development projects, it often is).

Communication, therefore, must happen at all levels. The delivery team need to understand the client’s requirements and ask them why they need a certain feature, then understand its job and who benefits from it.

The time and cost of not understanding or misinterpreting the client’s requirements or the delivery team’s feedback is known as the “cost of translation” or the “feedback delay”. If misunderstandings aren’t addressed in time by the delivery team, they could spend anywhere from a couple of weeks (using Agile) to years (using Waterfall) developing a solution that does not fulfil the client’s actual requirements.

Eliminating translation costs

BDD is a practice that can help solve this problem of miscommunication between the client and the delivery team.

BDD attempts to eliminate the cost of translation by reducing the size of the feedback loop and enforcing example-based conversations for each feature before it is built. This enables the delivery team to ask for examples from the client; clearing up any misunderstandings that may have occurred and ensuring conversations with the client typically happen within days (not weeks or years).

That in essence is what BDD is.

So to recap, BDD is about eliminating translation costs between the client and the delivery team using the language of examples.

Ubiquitous Language

But just asking for examples is not enough, because different sides will use different languages to produce examples, which will inevitably cause discrepancies. This is where the Ubiquitous Language helps.

“Ubiquitous Language is the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software – hence the need for it to be rigorous, since software doesn’t cope well with ambiguity.” – Martin Fowler

  • This is not a programming language
  • This is not a design language
  • This is not an architectural language
  • Clients can’t talk in a language that computers & code understand and vice versa
  • It is a business language and a technical language; a language that all entities or roles can use
  • The practice of creating this language, which we use within discussions throughout the project, is called Domain Driven Design

Summary

BDD gives the delivery team the ability to have conversations with the client on a business level, and in doing so allows them to come up with ideas on a non-technical level that will help solve various project challenges. The delivery team can then go off and write code for the client which fits with what was previously discussed. Decisions won’t get made at a coding level but will instead naturally get fed back to the client and discussed as a group as part of a collaborative effort – helping build “software that matters”.

About the author

Luke Quinnell

Luke Quinnell

Luke Quinnell is a Principal Developer at Box UK, working primarily with the Amaxus Content Management System developing core features and custom functionality. His main interests are PHP web development, User Experience and Information Architecture.

Comments

Stewart James

May 28th, 2015

An insightful article. The George Bernard Shaw quote “two nations divided by a common language” relates to the failure to communicate. It happens all the time in business, and translating business requirements into useable applications is just one example of this happening. Anything that reduces the likelihood of that happening and BDD would seem to be like using a “picture to paint a thousand words”

Add Your Comment

Related content

Tech round-up: Aug 19th

By Steve Anderson

Tech round-up: Jan 22nd

By Steffan Harries

We're hiring. Let's talk. View available roles