Behavior-driven development (BDD) is an agile process designed to keep the focus on stakeholder value throughout the whole project; it is a form of TDD. Specifications are defined in advance, the implementation is done according to those specifications, and they are run periodically to validate the outcome. Besides those similarities, there are a few differences as well. Unlike TDD, which is based on unit tests, BDD encourages us to write multiple specifications (called scenarios) before starting the implementation (coding). Even though there is no specific rule, BDD tends to levitate towards higher-level functional requirements. While it can be employed at a unit level as well, the real benefits are obtained when taking a higher approach that can be written and understood by everyone. The audience is another difference—BDD tries to empower everyone (coders, testers, managers, end users, business representatives, and so on).

While TDD, which is based on unit level, can be described as inside-out (we begin with units and build up towards functionalities), BDD is often understood as outside-in (we start with features and go inside towards units). BDD acts as an acceptance criteria that acts as an indicator of readiness. It tells us when something is finished and ready for production.

We start by defining functionalities (or behaviors), work on them by employing TDD with unit tests, and, once a complete behavior has finished, validate with BDD. One BDD scenario can take hours or even days to finish. During all that time, we can employ TDD and unit testing. Once we're done, we run BDD scenarios to do the final validation. TDD is for coders and has a very fast cycle, while BDD is for everyone and has a much slower turnout time. For each BDD scenario, we have many TDD unit tests.

At this point, you might have gotten confused about what BDD really is, so let us go back a bit. We'll start with the explanation of its format.