3 Great Reasons to use BDD
Through using and explaining BDD, I have become convinced that there are 3 main facets to the BDD approach. Understanding the incremental benefit and cost of these facets is key to guiding you on your BDD journey.
1) A common vocabulary for describing behaviours
Using the ‘Given, When, Then’ pro-forma for describing behaviour is the first, easiest to introduce and IMO, most important aspect of the BDD approach.
It is easy to get across to people without resistance because it is so simple, almost trivial. When I have introduced it to even skeptical teams the response has been oh, ok, thats how you do it, lets go.
The commonality of the approach is key. Everybody in the team can use this language to describe the intended behaviour of the system. Your BA folks don’t need to write separate specifications, your QA folks don’t need to write separate test cases and your Developers don’t need to write separate integration tests (but more about that in a moment). The Product owner can also see and understand exactly what he is getting without pouring over additional artefacts.
In short, your whole team can use this approach to simultaneously talk about quality, behaviour, user focused design and all agree on one description of the behaviour before moving on. This simple approach is enormously powerful and is compelling enough to use even without using the other 2 facets.
2) Automated test creation
A raft of clever tooling (JBehave, Cucumber etc…) has been created that allow you to take the textual descriptions of behaviour that you get from using ‘Given, When, Then’ and turn them into automated ‘black box’ tests. This usually involves writing some ‘glue’ or ‘steps’ code between the behaviour and the test.
Adding this to your BDD approach gives you the additional benefit of creating an automated test that both allows you to prove that the software works (and close a story in an Agile context) and give you an automated behavioural regression test that you can run over and over as the software evolves.
Note that you don’t need to introduce this tooling and approach in addition to using the vocabulary aspect. Indeed it does come with an additional cost. Turning the behaviours into tests invariably takes some additional effort. You need to weigh this additional effort with the double benefit of story closure and automated regression.
Using this facet of BDD requires careful consideration of the balance between cost and benefit and a firm eye on the medium and long term.
3) A ‘Test First’ Development methodology
This third aspect is BDD as an analog to TDD. TDD or ‘Test First’ development is a development discipline where you don’t write any code until you have a test to cover the code you are about to write. If you are using TDD, your development process looks a bit like this…
Write unit test -> Test goes ‘red’ -> write code until test goes ‘green’
When you overlay BDD into this methodology, your process might look a bit like this…
Create ‘black box’ Test -> Black box test goes red -> Write unit test -> unit test goes ‘red’ -> write code until unit test goes ‘green’ -> repeat unit test cycle until black box test goes green.
The key benefit of this approach is that your development team never writes any unnecessary code i.e. it prevents ‘over engineering’. The flip-side of this benefit and indeed the additional cost of this approach is related to refactoring. Because the developer is encouraged to write ‘just enough’ foundational code to support the current behaviour, as you introduce new behaviours, there is often a need to refactor those foundations.
This is by far the most controversial aspect to BDD. While most developers will agree that TDD is the best approach, there is no such consensus on ‘test first’ for BDD. Many developers want to design the foundations of their solutions with a broad vision of what it needs to achieve with quotes like “If I need to build a 3 story house, I need bigger foundations than a single story house. If I know this up front why not build the larger foundations first”.