I was introduced to Behaviour-Driven Development (BDD) about 5 years ago, about 2 years or so after I became a Quality Assurance engineer.
BDD as a movement has been around for more than a decade and it has evolved a lot in the past 5 years or so. In all the organisations I have worked at, including Funding Circle, I have seen recurring problems in adopting BDD principles. A lot of people still think BDD is a tool and is only about testing. For a long time I was one of those people too. I believe BDD is still poorly understood and frequently misappropriated.
Recently, the QA team and I went to the CukeUp conference here in London. Over the years,the CukeUp conference has usually been based around automated test and QA best practices, but this time there was a big push towards BDD with many people sharing best practices, new practices and experiences of where BDD has gone wrong and right.
So what did I take from the conference? Well I asked myself. BDD needs a description that makes sense. What’s in it for our Engineering and Product teams? Why should we adopt and try out BDD?
This is what I came up with based on my renewed understanding since the conference:
BDD is a set of principles and practices that enables technical teams to produce more valuable software with fewer bugs. Those who practice BDD should explore, discover, define, and then drive out the desired behaviour of software using conversations, examples and automated tests. BDD can lead to reduced development and maintenance costs.
Let me try and break these high level definitions down to something with a bit more context.
This is about learning early to fail less.
In traditional development practices, learning is amplified when functionality is tested or put in production in front of users. Useful feedback is gained but it usually requires the functionality to be built before any feedback is given. This is usually costly and causes delays in a team’s learning.
Then there’s the question: “what if the developers built the functionality wrong? Can we learn more before the defective code is written?
Deliberate Discovery and Exploration are principles that tell us to try to learn more before writing the software. As with any principles, the practice to support this is contextual. The practice that I have seen work well in many contexts is to carry out Discovery Workshops or, as many of us call them, Grooming Sessions.
In my view of BDD, Discovery Workshops are an effective practice that I have seen work well on projects here at Funding Circle. Involving non-technical stakeholders as well as developers and QA engineers is essential to for efficiency.
Talk About Examples
One of the things that come out of Grooming sessions is examples. These are business related (real world) examples of how the functionality should or could work, if it existed. The purpose of examples is to trigger discovery through conversations, but also to define how the functionality should behave.
Examples should show general constraints, rule and acceptance criteria. They do not have to be written in a particular form. Some teams write examples using Gherkin syntax (Given, As, When, Then, So), but this does not have to be the case. Sometimes starting using plain English is easier to have a conversation around.
At the conference this was best demonstrated using a BDD process by Matt Wynne (Co-founder of Cucumber) called “Example Mapping”. Example mapping doesn’t demonstrate anything that we are not practising already at Funding Circle, but it gives structure and organisation to the way we practice BDD which is what makes it awesome. We have already started the process to implement Example Mapping in an existing project.
BDD started out as TDD, replacing the word "test” with “should” to help people understand that TDD is not about testing, but about design and reflection. When it’s time to write code, I believe BDD is no different from TDD:
- Write a failing test.
- Watch it fail.
- Write enough code to make it pass.
- Clean up your mess (refactor).
So how does BDD differ from TDD? In a couple of areas:
- BDD gives you a well-defined starting point: The examples created by the deliberate discovery process.
- Tests that result from BDD are not unit tests, but high level tests that interact with the system at a much more granular level.
I don’t consider tools like RSpec to be a BDD tool. I think of it more as a unit testing tool that is great for TDD in the spirit of BDD. A tool like RSpec (fantastic as it is) is usually used at an abstraction level below the level that the non-technical stakeholders care about, and stakeholder involvement is key to BDD in my view.