Getting Started with Behavior-Driven Development
Editorial note: I originally wrote this post for the TechTown blog. You can check it out here, at their site. While you’re there, have a look around at the different training courses they offer.
You’ve probably heard of behavior-driven development (BDD). However, if you’ve never practiced it, you may perceive it as one of many in a nebulous cloud of acronyms. We have BDD, TDD, DDD, and ATDD. All of these have a “D” standing for “driven” and another one standing for either “development” or “design.” Apparently, we software developers really like things to drive us.
I won’t engage in a full “DD” taxonomy here, as this post concerns itself with behavior-driven development only. But we will need to take a tour through one of these in order to understand BDD’s motivations and backstory.
Behavior-Driven Development Origins and Motivation
To understand BDD, we must first understand test-driven development (TDD). Luckily, I wrote a recent primer on that. To recap briefly, TDD calls for you to address every new thing you want your production code to do by first writing a failing test. Doing this both verifies that the system currently lacks the needed functionality and gives you a way to later know that you’ve successfully implemented it.
With TDD, you deal in microtests. These distinguish themselves by being quite specific and granular. For instance, you might assert that you get a null reference exception when invoking a method with a null parameter. You’ll pardon non-technical project stakeholders for a distinct lack of interest in these microtests.
BDD evolved from asking the question, “Why don’t we do this for tests that the business might care about?” It follows the same philosophical approach and logic. But instead of worrying about null parameters and exceptions, these tests address the system’s behavior at the capability or feature level.
Behavior-driven development follows the TDD cadence: express a current system deficiency with a failing test. But this time the failing test is, for example, when I deposit money into my checking account, I can see the reflected balance. Work then proceeds on that feature until the test passes. At this time, the team considers the card complete.