According to AgileAlliance.org:

BDD (Behavior Driven Development) is a synthesis and refinement of practices stemming from TDD (Test Driven Development) and ATDD (Acceptance Test Driven Development).

That’s great, but what does that really mean?

BDD has its roots in TDD, but supersedes TDD in the agile development process.  BDD recognizes that User Stories are the framework for the development process and that these stories determine the necessary tasks required to satisfy given business requirements.  The overall process looks something like below:

bdd

Unlike, TDD, where unit tests are written first, BDD requires that acceptance tests are first written.  These acceptance tests are built around business requirements gathered from the stakeholders.  And, as Agile Alliance states, the process of gathering the requirements “[applies] the ‘Five Why’s‘ principal to each proposed User Story, so that its purpose is clearly related to business outcomes.”  Unfortunately, though, what may be “clear” to the business is often times obtuse to developers.  But, more about that in a minute.

Once the acceptance tests are written (for me as a consultant, I have my clients “sign off” on these tests to ensure that I deliver what they expect), following the standard TDD Fail-Pass-Refactor process, the tests should, of course, fail since code has yet to be written.  These acceptance tests are then converted to User Stories in my backlog.  In BDD, acceptance tests are wrapped in a Feature – there can be many acceptance tests (scenarios) for each feature.  And, these features are typically what are considered Epics in Agile development.  Therefore, most of the time, there’s a 1-to-1 correlation between an acceptance test (scenario) and a User Story, but this doesn’t always have to be the case.

Now that I have a clear definition of my User Stories and an understanding of the stakeholder’s expectations, I can determine the tasks required to implement each User Story.  And, following suite, unit tests can be written to test the successful implementation of each task.

The understanding is, that once I’ve implemented all tasks and all of my unit tests have passed, the accompanying acceptance test(s) for the User Story under development should also pass.  Once the acceptance test(s) for the User Story has passed, the business requirement has been met.

Let’s face it, what would the business rather you report? That you’ve completed “x” User Stories or that you’ve satisfied and successfully tested “x” business requirements?  Stakeholders often don’t know what a User Story entails, much less all the tasks required to complete the story.  But, a business requirement is something that is tangible – something the makes dollars and sense (ahh, see what I did there?) to them.