Behavior-Driven Development In A Nutshell

Behavior-Driven Development (BDD) is a process that gives examples of how software should behave in various scenarios. This behavior is written in a format that is easily understood, tested, and integrated.

Understanding Behavior-Driven Development

During the software development process, there are often one or more disconnects present:

  1. The business is unable to define the desired outcome(s).
  2. The developer has little understanding of what needs to be built. In other words, the needs of the business.
  3. The business, in turn, has little understanding of the technical challenges associated with building the product.

Fundamentally, the disconnect is caused by a lack of communication. BDD seeks to bridge the communication gap between the business and the developer, resulting in products that deliver value, meet goals, and fulfill expectations.

In the next section, we will take a closer look at how this is achieved.

Implementing BDD practices

BDD is an approach that incorporates elements of Test Driven Development (TDD) and Acceptance Test-Driven Development (ATDD). 

Indeed, developers who use BDD write acceptance criteria in a standard format that promotes clarity, easy integration, and automated testing.

These criteria consist of vocabulary that stakeholders, experts, and engineers can all understand and agree upon. 

Acceptance tests should be written using common templates such as the “Given-When-Then” formula or the “Role-Feature-Reason” matrix.

Each test in turn should be based on a user story using ubiquitous language.

For example, software that processes loan applications should ideally have classes such as LoanApplication and Customer.

To further simplify the process, BDD incorporates domain-specific language (DSL) which uses English-like sentences to express both behaviors and desired outcomes. 

Advantages and disadvantages Behavior-Driven Development

A business that is planning to implement BDD should be aware of the list of potential advantages and disadvantages to its software team.


  • Better communication. This is perhaps the most obvious benefit of BDD, but extremely important in delivering value and increasing process efficiency.
  • Shorter learning curve. Since BDD uses simple language, the learning time is naturally reduced.
  • Increased reach. Another benefit of simple language is that it can reach a wider audience. This promotes stakeholder engagement and fosters a sense of collaborative work toward a shared vision.
  • Discovery workshops. At the beginning of a project, BDD discovery workshops unearth additional capabilities and complexities. Specifications are detailed and described in terms of application behavior, so edge cases and many of the finer details are identified early. Ultimately, being aware of more scenarios initially leads to less rework during the later stages of the project.


  • Prior experience. Although the focus of BDD is on simplicity, it does assume that practitioners have some experience in Test Driven Development.
  • Incompatibility. The BDD methodology is incompatible with linear project management approaches such as the waterfall model.
  • Reliance on the Three Amigos. A critical component of BDD is the regular and collaborative nature of communication between the developer, tester, and business. When one or more of the amigos is unwilling to devote the time or effort to communicate, the validity of user stories is compromised.

Behavior-driven development example

To appreciate how behavior-driven development may function in the real world, let’s look at an example of an automotive company that is developing a self-driving vehicle.

Specifically, the company is developing software that allows the vehicle to respond to speed limit restrictions.

The description of the behavior starts with a feature, capability, or story within the bounds of certain acceptance criteria.

Remember that all of these are defined with terms from the customer’s domain.

With that in mind, below is the user story and associated acceptance criteria as defined by the automotive company:

As a driver,

I want the vehicle to identify the posted speed limit and maintain its speed at that limit

So that I can avoid paying attention to the speed limit myself.

Acceptance criteria: the car maintains its speed near or at the speed limit, but never above it.

We can also write the acceptance criteria using the Given-Then-When (GWT) formula mentioned in a previous section:

Given a posted speed limit

When the vehicle is moving

Then it is near the speed limit but not above.

The company then finds that the GWT formula is a little too ambiguous to code the story.

To provide some clarity, one or more scenario examples are formulated to specify the details of the behavior and define an acceptance test.

For example:

Given the posted speed limit is 75 kph

When the vehicle is moving

Then its speed is between 73 and 75 kph.

Developer, tester, and business collaboration

The Three Amigos then collaborate and additional acceptance criteria and scenarios start to become apparent.

Suppose that one of these reads as follows: When the posted speed limit decreases, the vehicle’s speed decreases without excessive force.

The team can use the GTW formula once more to define an acceptance test that defines an approved rate of deceleration.

In other words:

Given the posted speed limit is 60 kph

When the posted speed limit decreases to 50 kph

Then the rate of deceleration should be less than 10 meters per second squared.

Note that a similar formula could be applied when the vehicle enters a motorway and is required to accelerate to the speed limit.

Once the vehicle is traveling at speed on the motorway, the automotive company decides that a more substantial rate of deceleration may be required as the vehicle approaches a tunnel. 

The reasons for this are twofold. 

For one, all tunnels have a posted speed limit of 90 kph. They also have a speed camera at their entrance which necessitates that the car traveling at a motorway speed of 120 kph must decelerate more quickly to avoid the driver receiving a fine.

Based on this, more acceptance criteria that detail the story’s requirements must be developed.

For example: When the vehicle approaches a motorway tunnel, it decelerates at an appropriate rate to avoid the driver receiving a speeding fine.

Of course, additional tests must be created to define the appropriate rate of deceleration.

Criteria and tests should also be developed to clarify the distance at which the vehicle starts to decelerate upon approaching the tunnel.

Key takeaways

  • Behavior-Driven Development is a means of increasing the collaboration between business people and technical people during agile software development.
  • Behavior-Driven Development encourages teams to use simple language and concepts to formalize a shared understanding of how an application should behave.
  • If implemented successfully, Behavior-Driven Development increases collaboration, communication, and increased reach. However, it does rely heavily on total commitment from each of the Three Amigos.

Read Next: Business AnalysisCompetitor Analysis, Continuous InnovationAgile MethodologyLean StartupBusiness Model InnovationProject Management.

Main Free Guides:

Scroll to Top