Behavior Driven Development, or BDD, can help teams build the right product for end users. Although the term Behavior Driven Development is sometimes used interchangeably with Test Driven Development (TDD), many will posit that BDD is an extension of TDD because it helps development teams focus on business goals and code quality. While TDD provides tests that drive development, those tests may or may not help you determine whether or not you're meeting your business goals. Here's one definition:
- Behavior Driven Development start with business value, then drills down to feature sets, and teams receives feedback from the Product Owner
- Test Driven Development creates numerous tests that may or may not meet the business value, and feedback goes to the coder
Behavior Driven Development is considered more of an outside-in approach that is focused on business drivers. It takes TDD one step further -- you still need feedback on code quality -- because you can now get feedback on the feature.
So what is the general process to use Behavior Driven Development? It aligns well within the Agile framework and is one way to implement Agile. Teams should continue with their regular scrum activities: milestone planning, defining user stories, and acceptance criteria and developing, and iteratively repeat that process until ready to release.
Epics and Milestone Planning - this is a critical first step on the way to Behavior Driven Development. It helps teams identify their overarching business goals and how to deliver them.
User Stories / Behavior – address the WHY and WHO over the HOW. The typical format might look something like this:
- As a user, I want to easily add dates to my notes, so that I can sort by date created and updated.
Acceptance Criteria / Step Definition – Define the scenarios to meet your user story. In BDD, this is done in Given, When, and Then statements:
- GIVEN I am an user and I am creating a new note, WHEN I enter or update a note THEN the create/update timestamp is automatically added.
It’s important to try to stay away from UI specifics like “When I Click this Button”, because the UI can change and then your step isn’t really applicable. This is called the DECLARATIVE form.
The optimal time to do this is during backlog grooming. As with the user stories, defining acceptance criteria is an iterative process. The most critical thing is to not take a story into a sprint until the entire team agrees on the acceptance criteria. Many times, the definition discussion drives further questions or acceptance criteria, and helps get deeper clarity to the feature.
BDD is tool agnostic. There are tools out there to help automate this (Cucumber, JBehave, etc.), but the main goal is to get teams talking and to discover where more clarification is necessary. Remember, the conversations are much more important than the tools.