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.
- 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.|
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.
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.