Behavior Driven Development (BDD) is a software development process that originally
emerged from Test Driven Development (TDD).
According to Dan North, who is responsible for the evolution of BDD, “BDD is using examples
at multiple levels to create a shared understanding and surface uncertainty to deliver software
that matter.”
BDD uses examples to illustrate the behavior of the system that are written in a readable and
understandable language for everyone involved in the development. These examples include −
Converted into executable specifications.
Used as the acceptance tests.
BDD – Key features
Behavior Driven Development focuses on −
Providing a shared process and shared tools promoting communication to the software
developers, business analysts and stakeholders to collaborate on software
development, with the aim of delivering product with business value.
What a system should do and not on how it should be implemented.
Providing better readability and visibility.
Verifying not only the working of the software but also that it meets the customer’s
expectations.
Origin of BDD
The cost to fix a defect increases multifold if the defect is not detected at the right time and
fixed as and when it is detected. Consider the following example.
This shows that unless requirements are obtained correctly, it would be expensive to fix the
defects resulting from misunderstanding the requirements at a later stage. Further, the end
product may not meet the customer’s expectations.
The need of the hour is a development approach that −
Is based on the requirements.
Focuses on requirements throughout the development.
, Ensures that the requirements are met.
A development approach that can take care of the above-mentioned requirements is BDD.
Thus, Behavior Driven Development −
Derives examples of different expected behaviors of the system.
Enables writing the examples in a language using the business domain terms to ensure
easy understanding by everyone involved in the development including the customers.
Gets the examples ratified with customer from time to time by means of conversations.
Focuses on the customer requirements (examples) throughout the development.
Uses examples as acceptance tests.
BDD Practices
The two main practices of BDD are −
Specification by Example (SbE)
Test Driven Development (TDD)
Specification by Example
Specification by Example (SbE) uses examples in conversations to illustrate the business rules
and the behavior of the software to be built.
Specification by Example enables the product owners, business analysts, testers and the
developers to eliminate common misunderstandings about the business requirements.
Test Driven Development
Test Driven Development, in the context of BDD, turns examples into human readable,
executable specifications.
The developers use these specifications as a guide to implement increments of new
functionality. This, results in a lean codebase and a suite of automated regression tests that
keep the maintenance costs low throughout the lifetime of the software.
Agile BDD
In Agile software development, BDD method is used to come to a common understanding on
the pending specifications.
The following steps are executed in Agile BDD −
, The developers and the product owner collaboratively write pending specifications in a
plain text editor.
The product owner specifies the behaviors they expect from the system.
The developers
o Fill the specifications with these behavior details.
o Ask questions based on their understanding of the system.
The current system behaviors are considered to see if the new feature will break any of
the existing features.
Agile Manifesto and BDD
The Agile Manifesto states the following −
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work, we have come to value −
Individuals and interactions − over Processes and tools
Working software − over Comprehensive documentation
Customer collaboration − over Contract negotiation
Responding to change − over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
BDD aligns itself to the Agile manifesto as follows −
Agile Manifesto BDD Alignment
Individuals and interactions BDD is about having conversations.
over processes and tools.
Working software over BDD focuses on making it easy to create software that is of
comprehensive business value.
documentation.
Customer collaboration over BDD focuses on scenarios based on ideas with continuous
contract negotiation. communication with the customer as the development
progresses. It is not based on any promises.
emerged from Test Driven Development (TDD).
According to Dan North, who is responsible for the evolution of BDD, “BDD is using examples
at multiple levels to create a shared understanding and surface uncertainty to deliver software
that matter.”
BDD uses examples to illustrate the behavior of the system that are written in a readable and
understandable language for everyone involved in the development. These examples include −
Converted into executable specifications.
Used as the acceptance tests.
BDD – Key features
Behavior Driven Development focuses on −
Providing a shared process and shared tools promoting communication to the software
developers, business analysts and stakeholders to collaborate on software
development, with the aim of delivering product with business value.
What a system should do and not on how it should be implemented.
Providing better readability and visibility.
Verifying not only the working of the software but also that it meets the customer’s
expectations.
Origin of BDD
The cost to fix a defect increases multifold if the defect is not detected at the right time and
fixed as and when it is detected. Consider the following example.
This shows that unless requirements are obtained correctly, it would be expensive to fix the
defects resulting from misunderstanding the requirements at a later stage. Further, the end
product may not meet the customer’s expectations.
The need of the hour is a development approach that −
Is based on the requirements.
Focuses on requirements throughout the development.
, Ensures that the requirements are met.
A development approach that can take care of the above-mentioned requirements is BDD.
Thus, Behavior Driven Development −
Derives examples of different expected behaviors of the system.
Enables writing the examples in a language using the business domain terms to ensure
easy understanding by everyone involved in the development including the customers.
Gets the examples ratified with customer from time to time by means of conversations.
Focuses on the customer requirements (examples) throughout the development.
Uses examples as acceptance tests.
BDD Practices
The two main practices of BDD are −
Specification by Example (SbE)
Test Driven Development (TDD)
Specification by Example
Specification by Example (SbE) uses examples in conversations to illustrate the business rules
and the behavior of the software to be built.
Specification by Example enables the product owners, business analysts, testers and the
developers to eliminate common misunderstandings about the business requirements.
Test Driven Development
Test Driven Development, in the context of BDD, turns examples into human readable,
executable specifications.
The developers use these specifications as a guide to implement increments of new
functionality. This, results in a lean codebase and a suite of automated regression tests that
keep the maintenance costs low throughout the lifetime of the software.
Agile BDD
In Agile software development, BDD method is used to come to a common understanding on
the pending specifications.
The following steps are executed in Agile BDD −
, The developers and the product owner collaboratively write pending specifications in a
plain text editor.
The product owner specifies the behaviors they expect from the system.
The developers
o Fill the specifications with these behavior details.
o Ask questions based on their understanding of the system.
The current system behaviors are considered to see if the new feature will break any of
the existing features.
Agile Manifesto and BDD
The Agile Manifesto states the following −
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work, we have come to value −
Individuals and interactions − over Processes and tools
Working software − over Comprehensive documentation
Customer collaboration − over Contract negotiation
Responding to change − over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
BDD aligns itself to the Agile manifesto as follows −
Agile Manifesto BDD Alignment
Individuals and interactions BDD is about having conversations.
over processes and tools.
Working software over BDD focuses on making it easy to create software that is of
comprehensive business value.
documentation.
Customer collaboration over BDD focuses on scenarios based on ideas with continuous
contract negotiation. communication with the customer as the development
progresses. It is not based on any promises.
