Why You Should Care About Behaviour-Driven Development
Agile has helped us move away from creating upfront precise requirements into working with smaller pieces of ideas, but we still have a huge amount of waste with lots of discovery and misunderstandings late in the process, even in short sprints, Matt Wynne states in a recent overview of Behaviour-Driven Development, BDD.
A key problem BDD is meant to improve is the communication between people working in the problem domain and in the solution domain, Matt, lead developer for Cucumber, (an open source tool for BDD), further explains. BDD is meant to create and grow a common area of understanding between the two domains, to create a common language, an ubiquitous language as defined in Domain-Driven Design, DDD.
User Stories is an agile tool helping us describe requested functionality. To better understand these stories before turning them into working features, BDD uses concrete examples to explore how we would use the described functionality. They are also a cheap way to find edge cases in an early stage instead of discovering these later on when it’s much more expensive to fix them.
An advantage with BDD focusing on examples to explore the problem domain is also that everyone can get involved, from users and stakeholders to developers and testers; examples are not technical, basically all you need is pen and paper or something similar.
When looking into the solution domain, Matts' experience is that teams, as a project evolves, often finds it harder and harder to introduce a change into the codebase. Matt compares a codebase with a kitchen; a well-organised clean kitchen makes it easier to produce high-quality food. To keep a kitchen clean means constantly washing up, putting things away etc., and a professional working environment needs to have the same strategy. In a codebase the equivalent to washing up in a kitchen is refactoring; changing the design without changing its behaviour. The codebase gets a little bit more organised, a little bit easier to understand and change.
To ensure that behaviour is not changed during refactoring automated tests are needed, e.g. by using Test-Driven Development, TDD, and BDD which both use examples to clarify requirements.
You won't stay agile without clean code
BDD was developed around 2006 by Dan North who has written both an introduction and about stories from a BDD perspective.
Specification by Example is a way of defining requirements closely related to BDD.
Cucumber is an open source tool for Behaviour Driven development, BDD, currently for nine programming languages, including JVM-based languages. A new version, Cucumber Pro for the Enterprise was recently released.
Anatole Tresch Mar 03, 2015