BDD 101: Introducing BDD

BDD 101 is a blog series to teach the basics of behavior-driven development. It is both a “getting started” guide for BDD beginners, as well as a best-practice reference for pros. I wrote this series for anyone involved in the daily duties of software development: developers, testers, scrum masters, product owners, and managers. The content in this series comes from my experiences using BDD for many projects. Of course, test automation through BDD will be a major theme in this series.

If this series is for you, then let’s dive in!

What is BDD?

Behavior­-Driven Development (BDD) is a test­-centric software development process that grew out of Test-­Driven Development (TDD). It has been around since roughly the mid-2000s. BDD focuses on clearly identifying the desired behavior of a feature from the very start.  It captures a product’s behavior as a set of “given-­when-­then” scenarios written in a domain-specific language called Gherkin, which serve as both the product’s requirements/acceptance criteria (before development) and its test cases (after development). With the help of automation tools, scenarios can easily be turned into automated test cases. Anybody from engineers to product owners can write BDD scenarios, since they are just English phrases. BDD keeps developers focused on delivering precisely what the product owner wants. It also expedites testing. As such, BDD pairs nicely with Agile Software Development.

Quick Points

  • BDD is Given-When-Then.
    • When someone says “BDD”, immediately think of “Given-When-Then”.
  • BDD focuses on behavior first.
    • Behavior scenarios are the cornerstone of BDD.
  • BDD is a refinement of the Agile process, not an overhaul.
    • It formalizes acceptance criteria and test coverage.

The Origins of BDD

The following quote comes from an article entitled Introducing BDD, written by Dan North (the “Father of BDD”) in March 2006:

I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.

The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.

My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.

12 Awesome Benefits

BDD improves the development process in a dozen ways:

Inclusion Anyone can write BDD scenarios, because they are written in plain English. Think of The Three Amigos.
Clarity Scenarios focus specifically on the expected behavior of the product under development, resulting in less ambiguity for what to develop.
Streamlining Requirements = acceptance criteria = test cases. Modular syntax expedites automation as well.
Shift-Left Test case definition inherently becomes part of grooming.
Artifacts Scenarios form a collection of test cases. Any tests not automated can be added to a known automation backlog.
Automation BDD frameworks make it easy to turn scenarios into automated tests.
Test­-Driven Most BDD frameworks can run scenarios to fail until the feature is implemented.
Code Reuse “Given-When­-Then” steps can be reused between scenarios.
Parameterization Steps can be parameterized. For example, a step to click a button can take in its ID.
Variation Using parameters, example tables make it easy to run the same scenario with different combinations of inputs.
Momentum Scenarios become easier and faster to write and automate as more step definitions are added.
Adaptability Scenarios are easy to rewrite as the products and features change.

Testing Recommendations

Since BDD focuses on actual feature behavior, Gherkin scenarios are best for higher-level, functional, black box tests. For example, Gherkin is great for testing APIs and web UIs. Gherkin excels for acceptance testing. However, Gherkin would be overkill for unit tests, and it is also not a good choice for performance tests that focus on metrics and not pass/fail results.

Next Steps

Lost yet? Don’t worry – this first post presented a lot of information. Things will make much more sense after learning how to write Gherkin test scenarios, which will be covered in the next post in this 101 series.

6 thoughts on “BDD 101: Introducing BDD

  1. Pingback: BDD 101: The Gherkin Language – Automation Panda

  2. Pingback: BDD 101: Writing Good Gherkin – Automation Panda

  3. Pingback: 12 Awesome Benefits of BDD – Automation Panda

  4. Pingback: The Behavior-Driven Three Amigos – Automation Panda

  5. Pingback: Python Testing 101: Introduction – Automation Panda

  6. Pingback: 10 Gotchas for Automation Code Reviews – Automation Panda

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s