A QUICK SUMMARY – FOR THE BUSY ONES
TABLE OF CONTENTS
Behavior Driven Development is a high-level software project methodology where we make use of the “outside-in” technique.
It means that we first figure out the outside layer, which is the needs of a business. Then we figure out the requirements and features and finally, we fulfill the given criteria in order to make our product work.
In this article, we’ll find out what BDD is and how it can be used in a project.
Software or digital product development is undoubtedly one of the most crucial parts of many businesses. There are techniques which help to ease the process by breaking up the work into smaller tasks and then deriving a solution. During this phase, many teams tend to forget one of the key elements of a successful project, which is to fulfill the specific requirements of a business.
A business idea can be abstract and thus make it hard to come up with a good solution. To overcome such problems, we always start our development process with an idea. These ideas represent our main goal and they power up the software development cycle.
Now in the case of Behavior Driven Development, our first step is to convert the given idea into requirements that come between the outside and inside layer (usually referred to as the intermediate level).
For example, if a Business Analyst says that we need to increase our user involvement with the product by a certain factor, our requirement will be to create a service that allows the user to give feedback after logging into the website.
So here we specified 2 requirements:
Here we also specify the requirements in such a manner that everyone can understand it. To accomplish such flexibility we create a story-driven implementation. The story acts like a natural language that is understood by everyone and is descriptive with an expected outcome. It helps the programmer to understand the real problem.
The Behavior Driven Development is quite similar to TDD (Test Driven Development) but it focuses on the discussion among team members.
So we talked about how the story plays a crucial role in a software development cycle but there is another part of Behavior Driven Development where we make use of specifications rather than stories.
With specifications, we focus more on functionality rather than the use case of that particular problem. For obvious reasons, it is more technical and not used so often by business personnel.
Let’s say we are working on user authentication. In terms of specifications, we might talk about the fields required for the user login. The specifications can be name, password, email, etc. Then we will discuss how tokens should be generated and then how to validate them in order to send authorization.
But you have to be particularly careful while writing the specifications. They must be easy to read. Your tests also should be small and test only one thing and not the entire application.
Your tests should be sentences and the testing framework that you use should do this automatically for you.
In Behavior Driven Development, our main idea is to allow interaction between business interests and technical insights.
So the requirements usually get generated from a business perspective and get fulfilled through technical solutions. To fulfill the requirement, you have a proper understanding of it and hence we create a scenario where we specify the role and action and based on that, we predict the outcome. So, in short, we create a User Story with predefined actions and outcomes.
The User Story helps in many ways:
The “outside-in” methodology is an iterative process. At first, we may gather the requirements from users. Based on that, a Business Analyst can form an idea and identify the requirements. Now Business Analysts will share the details with the technical staff.
When it comes to implementation of BDD, we need to follow some rules which are pre-defined. So to write our story we define certain scenarios and based on that we follow a format called Gherkin language to develop our features.
So let’s take one example and consider this structure:
Scenario: A user can log into the app
Given: I empty the "User" table
And I create the following users:
| id | email | username | password |
| 1 | [email protected] | Brainhub | randompassword |
When I log in with username "Brainhub" and password "randompassword"
Then I am logged in
Here is a typical user story format:
Title: (one line describing the story)
As a [role] I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
And [some more context]...
And [another outcome]...
To understand this, let’s go back to our previous example. Our aim was to increase user engagement. So here we called our feature “feedback” and after defining our feature, we talked about scenarios. Scenarios are part of a story which specify an action and expects one output.
For any scenario we need to define:
A User Story is good as long as there are detailed scenarios. In short, one must cover all the possible scenarios in order to have a better understanding of the working of the software. This includes all the possible edge cases.
Another main point is that the story needs to be small enough that it is iterative in nature. This means that we can break the larger problem into smaller parts and then solve all the smaller parts one by one with each scenario to meet the requirements. As a result, a business team can understand the work and easily understand the progress on the development with its efficiency.
Once we finalize the story and the scenarios which are possible, we start our software development process by iterating over the scenario and fulfilling it one by one. In other words, the given software must pass all the test cases written by us as features and scenarios.
You must be wondering how programmers take those features and scenarios and turn them into test cases. Well, in most cases, they take these sentences and map them into functions. So as soon as those test cases start, the mapped functions get triggered and start the software with given test cases.
At the end of the day, Behavior Driven Development is about streamlining the whole development process and delivering value. What is BDD? It’s not just a mere toolset. It’s a mindset. BDD can teach Business Analysts and testers effective ways to discover requirements, and it can help developers write higher-quality and more maintainable code.
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Full-stack software developer with 17 years of professional experience.
Software development enthusiast with 8 years of professional experience in this industry.
Top reads this month
Get smarter in engineering and leadership in less than 60 seconds.
Join 300+ founders and engineering leaders, and get a weekly newsletter that takes our CEO 5-6 hours to prepare.
No previous chapters
No next chapters