Behaviour-Driven Development (BDD) recognizes that software development is fundamental to business of today and helps to improve communication between business stakeholders and software developers, Kevin Smith claims in a recent blog post about his experiences working with BDD.
After many years of running agile projects, Smith, Technical Director and Co-founder of Dootrix, has noticed a few general shortcomings:
- With user stories’ focus on the user and what she is trying to achieve it’s easy to forget about the business needs.
- User stories are short-lived, making it easy to forget about the overall specification of an application.
- Acceptance criteria, based on user stories, are often of too low quality, among other things due to user stories being short-lived.
- The agile toolbox lack tools which help to find the business problems that need to be solved.
- Test-driven development (TDD) is commonly used today, but too often these tests only verify the details, not that features are correctly implemented.
In Smith’s experience, BDD helps in solving these issues, especially by introducing concepts like Specification by example and Impact mapping.
One simple change Smith has implemented is changing the user story template to a more BDD-style form, which he thinks puts an increased focus on business value, ensuring that it's always discussed:
In order to <realize benefit> as a <role> I want <feature>
BDD emphasizes concrete examples to minimize ambiguity. These examples help in creating a common understanding as well as finding missing functionality, and can also be used when writing acceptance criteria, A formal language, Gherkin, can be used to write these examples which makes it possible to automatically run tests based on the examples.
A common challenge when building software is creating correct documentation. Since BDD has a focus on features with examples to explain the behaviour, it can be used for automating the documentation, which then will be in sync with the actual features implemented, often called living documentation.
Although Smith thinks that BDD has a lot offer, there is still some potential drawbacks to be aware of:
- BDD is not about the user interface, so we still need to work with prototypes and other tools to ensure the interface is well designed.
- There are many tools available for creating tests from the examples written, but there is a lack of tooling for managing which tests are run and when.
- It can be hard to develop a good automated testing suite, and in the short term it is more expensive.
Smith concludes by noting that BDD is still a young idea and lacking the ecosystem that is found around agile. Still, he believes it's a step in the right direction, helping to improve the communication between people when building software. To emphasize what BDD is really about, he cites Dan North, who created BDD:
Above all BDD is a mechanism for fostering collaboration and discovery through examples.