If you have practiced Test Driven Development (TDD) is that BDD drives its value from principles of TDD (which focus on incremental design delivery) where the Software development team(Product owner, Business Analyst, Development and Testers) incrementally create common and shared understanding of the next most valuable behavior to build in the system to realize the best incremental value.
This required behavior is captured as specification in Acceptance tests and its scenarios and developed incrementally using BDD with focus on Behavior of the System under envelopment not its implementation details.
BDD concepts and practices are promoted by Dan North, who realized the during his TDD training classes that TDD is too Test focused and has probkem. In his words –
“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”
Definition from Dan North, the creater of the BDD approach is as follows:
BDD Descroption from Dan North during
BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.
Simple Introduction
Let’s make it simple for everyone to understand. Let’s try to understand the follow question:
Assuming What happens between team members (Product owner, Developer , Test engineer) developing a User Story?
–
BDD Practice
Scenario: Inventory should be checked for each item before confirming an order
- Given a customer has filled the shopping cart with an order of multiple items
- and the inventory store is available for access
- when he activates the request for the order placement
- then all items in the order should be verified for availability in the inventory
public class OrderVerificationTest{
@Test
public void shouldEnsureThatOrderItemsAreAvailableInInventory() {
Inventory invnt= MOCK(Inventory.class);
Order order = new Order();
order.addItem("item1");
order.addItem("item2");order.placeOrder(); //check if the invnt.checkAvailability(item) is called twice,once for each item in the order when placeOrder() is called; }}
What is the advantage?
Collaboration: BDD brings all customers (or PO, BA representations ) together in describing the behavior of the system.
Ease of implementation change: The behavior of the system under design and implemenation hardly chnages. Its the implmentation of the system behavior that can chnage. If the Behavior chareteristics are static, why not have them abstracted out in a structure which is independent of how the final implemnattion. This is great advantage of BDD. Think and
Ubiquitous language for stake holders:
Ease oif Refactoring:
Process of BDD:
Tools for BDD
1) Fitnesse
2) Twist
3) JBehave
4) Cucumber for Ruby
5) Rspec for Ruby
6) Specflow for .NET
7) CBehave: A Behavior Driven Development Framework for CLanguage for BDD:
Given:
When:
Then:Following are some good links on BDD:1) Introducing BDD by Dan North.
2) BDD is Like TDD by Dan North.
3) Short description of BDD – BDD in Nutshell by Rachel Davies
4) Wikipedia page on BDD.
5) Liz Keogh’s blog on BDD
6) IBM article. Very good example driven introduction of BDD – In pursuit of code quality: Adventures in behavior-driven development
7) BDD approach to defining and identifying stories – Whats in a story?
8) Good stackoverflow discussion
9) Another small example for JBehave BDD users by Giordano Scalzo’s Personal Blog
10) Good Presentation slides on BDD and JBehave by Nikolay Vasilev.
11)
Technodeation 