Behaviour-Driven Development

Behaviour-Driven Development^[5] (BDD) builds upon Test-Driven Development (TDD) by formalizing the good habits of the best TDD practitioners. The best TDD practitioners work from the outside-in, starting with a failing customer acceptance test that describes the behavior of the system from the customer’s point of view. As BDD practitioners, we take care to write the acceptance tests as examples that anyone on the team can read. We make use of the process of writing those examples to get feedback from the business stakeholders about whether we’re setting out to build the right thing before we get started. As we do so, we make a deliberate effort to develop a shared, ubiquitous language for talking about the system.

Ubiquitous language

As Eric Evans describes in his book Domain Driven Design [Eva03], many software projects suffer from low-quality communication between the domain experts and programmers on the team:

“A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design... Across this linguistic divide, the domain experts vaguely describe what they want. Developers, struggling to understand a domain new to them, vaguely understand.”

With a conscious effort by the team, a ubiquitous language can emerge that is used and understood by everyone involved in the project. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is gone, and the chances of misunderstandings are greatly reduced.

Cucumber helps facilitate the discovery and use of a ubiquitous language within the team, by giving the two sides of the linguistic divide a place where they can meet. Cucumber tests interact directly with the developers’ code, but they’re written in a medium and language that business stakeholders can understand. By working together to write these tests—specifying collaboratively—not only do the team members decide what behavior they need to implement next, but they learn how to describe that behavior in a common language that everyone understands.

When we write these tests before development starts, we can explore and eradicate many misunderstandings long before they ooze their way into the codebase.

Examples

What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team. This reveals the true value of acceptance tests: as a communication and collaboration tool. The easy readability of Cucumber tests draws business stakeholders into the process, helping you really explore and understand their requirements.

Here’s an example of a Cucumber acceptance test:

Notice how the test is specified as examples of the way we want the system to behave in particular scenarios. Using examples like this has an unexpectedly powerful effect in enabling people to visualize the system before it has been built. Anyone on the team can read a test like this and tell you whether it reflects their understanding of what the system should do, and it may well spark their imagination into thinking of other scenarios that you’ll need to consider too. Gojko Adzic’s book Specification by Example [Adz11] contains many case studies of teams who have discovered this and used it to their advantage.

Acceptance tests written in this style become more than just tests; they are executable specifications.