Behaviour Driven Development

BDD is a formalised template for User Stories. BDD is able to create testable User Stories since they are defined in a formal manner. It Promotes “security” to a first call citizen in the analysis process.
 

What are the goals of BDD ?

• Drive application development based upon Business Value.
• Write tests before you write code.
• Work in small increments of work.
• Provide the development team an ability to refactor code quickly.
• Designed to illustrate the behavior of a feature.

 

What are the Benefits ?

• Reduce the time for code implementation.
• Specifying via example will lead to more modularized, flexible, and extensible code.
• Encourages close teamwork between the entire Project Team.
• Gojko Adzic has extended the concept of BDD pushing teams to have a broader contextual understanding of a Feature.
• Specification by Example is the process by which teams build software through the effective use of Examples.
• Defining requirements through examples allows the entire team to provide input to the contextual definition of the feature.
• Behavior = Examples = Context = Acceptance Criteria
• Each row in an Example table is considered an individual test, how it gets developed (ie unit, integration, automation or manual) is up for the team to deteremine.

 

What’s the Process of BDD ?

• Identify Acceptance Criteria (Examples) that supports a User Story/Feature before any code is written.
• Have a complete review of the Examples and obtain sign off from the team before starting coding.
• Coding is complete, and a feature can be implemented, when all the Acceptance Criteria (aka Examples) pass.

 

What are the Benefits of Examples ?

• Creates business value, because only what is needed to support the feature is coded, nothing more, nothing less.
• Quality increases when developers understand how the feature will be used.
• Sprint quality improves with Agile/BDD zero defect policy.

Who is Responsible ?

• The entire Team contributes to the process of building Examples.
• Functionally teams will typically designate a sub group of people who are responsible for the development of the initial Example Specifications then the entire Team will review and provide sign off that the Examples are complete.
• Examples = Acceptance Criteria

Building Examples

Behavior Driven Development provides the following process for defining a testable feature:

• Given <some precondition>
• And <additional preconditions
• When <an action/trigger occurs>
• Then <some post condition>
• And <additional post conditions>

Use And to provide further context for the feature.

• Similar to Use Case development

What’s the Story ?

Review User Stories in order to create a Test Scenario Outline
Why? To confirm that you understand stories sufficiently in order to identify tests that will support them.
Example– As a customer, I want to withdraw cash from an ATM, so that I don’t have to wait in line at the bank.
 
I. Use short descriptive names for your Test Scenarios:
Example: Scenario 1 – Account is in Credit
 
II. Each Scenario should represent a Different Facet of the User Story
Example: Scenario 2 – Account is Overdrawn
 
III. Identify All the Variables that need to be supported in the User Story
What are considered customers (personal, business, corporate)?
What are considered accounts (savings, checking, credit)?
 

Building the Test – Given and Preconditions

Feature/Story:	As a customer, I want to withdraw cash from an ATM, so that I don’t have to wait in line at the bank.
Scenario 1	Account is in Credit
Given Statement	Given I’m a customer with a valid account And My Account is in Credit
Scenario 2	Account is Overdrawn
Given Statement	Given I’m a customer with a valid account And My Account is Overdrawn