In software engineering, behavior-driven development (BDD) is an Agile software development process that aids the management and the delivery of software development projects by improving collaboration among developers, QA, and non-technical or business participants in a software project.
Explanation of BDD in Simpler Terms.
BDD emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.
With this process of collaboration, BDD ensures all development projects remain focused on delivering what the business needs while meeting all requirements of the user.
Benefits of BDD
All development work can be traced back directly to business objectives.
Software development meets the user's need. Satisfied users = good business.
Efficient prioritization — business-critical features are delivered first.
All parties have a shared understanding of the project and can be involved in the communication.
A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression.
Improved quality code reducing costs of maintenance and minimizing project risk
Principles of BDD :
Generally working with the BDD can be categorized into three parts
Given — It is the initial stage of the process.
When — This is the place where the action takes place.
THEN — This is the place where the expected outcome is given.
BDD is the extension of TDD ( Test Driven Development) i.e. continue development of TDD which makes more specific behavior choices than TDD.BDD specifies that the user needs to do testing in terms of desired behavior rather than traditional testing methodology like
define a test set for the unit first,
make the test fail
then implement the unit
finally, verify the implementation of the unit and pass the test.
BDD relates to how the desired behavior with help of user stories.
In a software project company, the user story is like the normal language description of the features that are going to be built into the software system.
They are drafted keeping the end-user i.e. client user in the mind. Depending on the projects and requirements by the client the user stories are written by different end-user, stakeholders, and development teams and it will be easily understandable for a lay term with ( written in natural language — so that it can be easily understood).
Simple Template of User Story
As a <role i.e. developer/tester/end user/Client> I can <capability / doing task >, so that <receive benefit>
As a user, I can visualize the sales data in bar chart style with sales executed per month.
Generally, User Story will follow the structure like below.
User Story Structure [Source: Wikipedia]
One of the core concepts in Behavior Driven development is using the ubiquitous language from Domain-Driven Design (DDD). Ubiquitous language is nothing but the simple formal language that is collaborated among all members and all teams of the software development team i.e. both technical and non-technical staff. This ensures that communication will be guaranteed between all the members or personnel involved in the software project. DDD is nothing but the using the domain level language i.e. understandable by the Client should be used throughout the software development phases like development and testing and delivery to the client. With DDD, all the team's developers, tester, business analysts, project management, and all other personnel involved in the project can easily understand others since everyone uses the domain-specific language ( one example is ubiquitous language). This helps in increase in efficiency and reducing the cost of the translation and cost of working with different language barriers.
Three Friends — Three Amigos
Business — The role of the Business user is to define the problem only (and not venture into suggesting any solution)
Development — The role of the Developers involve suggesting ways to fix the problem
Testing — The role of testers is to question the solution, bring up as many different possibilities for brainstorming through What-If scenarios and help make the solution more precise to fix the problem.
Thus, BDD emerges from the TDD which uses the tools and methodologies to achieve the testing the goals faster and efficient.