Behavior-driven development

BDD is an extension of the concepts of TDD to the complete functioning of a software system. Indeed, according to some proponents, BDD is a method for operating an entire organization!

Whereas TDD is concerned with tests and code, BDD is concerned with behaviors and benefits. BDD attempts to express the behavior of a system in plain, human language and justify the benefits that the behavior provides. TDD is written in code and does not attempt to justify the value of any part of the system. The loftiest vision of BDD is a methodology by which all features are specified and justified in clear human language, which can automatically be executed to verify that the system works as expected. Some other names sometimes used to refer to this lofty vision of BDD are Specification by Example and executable documentation.

If we look at our AddressValidator example, mentioned previously, we have an example of TDD. If we were to create a BDD-oriented specification for it, we may start with something like this:

Feature: Address Validation
  As a postal customer,
  In order to ensure my packages are delivered,
  I want to validate addresses

Scenario: Invalid address
  Given I enter "Seoul, USA"
  When I validate the address
  I should see the error message, "City and Country do not match"

This is the beginning of a Cucumber example. We won't go into Cucumber any further in this book, but it should be noted that RSpec is a closely related tool, and many of the developers who contribute to RSpec also contribute to Cucumber.

In the real world, the piding line between TDD and BDD is not that clear. For most practical purposes, the only difference between TDD and BDD is in the style of the syntax used for expressions.

TDD leans more toward programmatic syntax, such as:

assert_equal(x, 5)

BDD, however, would use a syntax closer to human language, like RSpec's:

expect(x).to eq(5)

For the purposes of this book, we will strike a practical balance between TDD and BDD. Just by using RSpec, we are getting a hefty dose of BDD in our syntax. But we can still choose to structure our tests to follow the structure of our code (for example, having a single test for every function), which are nothing but unit tests. We can also choose to structure our tests according to high-level features, which is closer to BDD, or integration tests. In fact, we need to do a bit of both of these kinds of tests, as well as some tests that fall in between, which are sometimes called functional tests.