When the desired outcome of a new project has been defined, Behaviour-Driven Development (BDD) can help in overcoming the gap between the developer’s understanding of what needs to be built and the business’ understanding of the technical challenges caused by the requirements. The reason is improvement in communication between the two groups, Alistair Stead and Konstantin Kudryashov, both working for Inviqa, explains in their Beginner’s guide to BDD, targeting both business and technical professionals.
Stead and Kudryashov divides BDD into two main practices; using examples written in a ubiquitous language to describe behaviour, and using those examples as the basis of automated tests. Together these two practices can validate the functionality for the user and that the system behaves as defined throughout the project lifetime.
The key elements in BDD that Stead and Kudryashov point out include:
- Creating a goal from a business perspective that preferably is specific and measureable at the start of a project.
- Impact Mapping, a way of finding the features most important for the business to reach the set goals. An impact map visualizes why features are needed and whose behaviour should be changed to achieve the goals.
- Complexity analysis, a way to find the most appropriate development and collaboration approach, one example being Cynefin.
- Planning in examples to avoid misunderstanding by using examples to describe business rules and provide context. These examples should then also be converted into tests used during development.
- Ubiquitous language, a term from Domain-Driven Design (DDD) for a language shared by developers and business people to reach a common understanding of the terminology in a domain.
- Development through examples. By using a formal language and an automation tool like Cucumber, examples can be turned into executable specifications for verifying implemented features.
- The BDD loops enable a support for large changes of a system. Using executable specifications and by treating unit tests as object specifications for how individual pieces of a system should behave, an ability to handle both large and small changes can be achieved.
In an interview with Dan North, who developed BDD around 2006, he emphasizes that BDD is not about testing, it’s about writing examples and expectations to describe behaviour of an application before it exists and by this causing people within a project to talk to each other. North notes the importance of keeping people close to each other, separating structurally or geographically can be a big obstruction to succeeding with BDD.