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.
“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 & feedbackIn a typical software development project you will have three ‘entities’ or ‘roles’:
- 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
- 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
- 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.
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
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”.