If you know about Unit Testing and Test Driven Development, you might have heard about Behavior Driven Development or BDD. BDD was first described by Dan North in an article that was published in 2006. The exact definition of BDD given by him can be translated into any language and still won’t make much sense :).
Personally when I am learning about new technologies, I try to understand their use and the reason for their existence. Remember the old saying
Necessity is the mother of invention
I strongly feel that whenever a new technology is introduced, it is the bi-product of someone missing something. With the conventional TDD style of development our focus is more on testing the happy and sad paths of code. While doing that we also write a more cleaner and easy to use API as we think about how the client will interact with our code.
With BDD we are more focused on achieving specific behaviour of the system. It is much like a beautiful scene that you want to capture but you have to decide what the object of your focus will be just like the flower in the image on top. So with BDD instead of building the system from inside out, we start building it from outside in. We define the behavior of the system and then try to achieve it. While achieving that behavior we are able to identify the attributes required to achieve the behavior. Remember that in BDD your focus is always on the behavior and attributes of data are identified along the way.
If you search around for BDD you will see that many people think of BDD as some sort of technique that requires you to use some specific tools. There are many tools out there that help you with BDD development such as:
-
SpecFlow
-
NSpec
-
StoryQ
-
MSpec (and the list goes on)
The very important thing to remember for anyone beginning BDD is to understand that it is just a methodology. It’s a way of implementation and although tools can help you achieve things quickly, you do not need any extra tool to start doing BDD.
BDD tends to make development practices from accessible by shifting the vocabulary from being test-based to behavior-based. It emphasizes communication and automation as equal goals. Communication is the essence of BDD.
Getting Started
To get started with BDD, you need to identify the user stories. Normally the user stories are written in the well-known format of
As a
[role], I want [goal/desire] so that [benefit]
Some examples of user stories can be:
As a debit card holder, I want to withdraw cash from ATM so that I don’t have to go to the bank.
As a student, I want to login to the college website so that I can view the exam’s result.
Once we have a user story, we try to identify the scenarios that cover the story. This is the part where a lot of group discussion takes place between stakeholders, testers, developers and QA people. They try to come up with concise and limited scenarios for the acceptance of the user story. If all the scenarios decided here are implemented, then the user story is formally completed.
The scenarios are written in the following format
Given [initial context], when [event occurs], then [ensure some outcomes]
Some examples of scenarios can be as follows:
Given a valid pin, when the card holder enquires balance, then he should be displayed his available balance.
Given an Invalid pin, when the card holder tries to access the options menu, then he should be displayed the message “Invalid pin, Please re-enter your pin.”
From the above examples you can see that we are defining the behavior of how an ATM will work but there are tech words there. The primary focus is on how the system (ATM in this case) will behave.
You can see from the above examples that it would be very easy for a developer to implement the above behavior and verify it. Once you have verified by the aid of unit tests that your system is meeting all the scenarios then you can mark the user story complete and move on. BDD is more effective and productive because it involved all the stake holders and all of them unanimously decide when a user story or feature is done, there are no chances of ifs and buts if you go along the path of BDD
If you are completely new to TDD then I strongly suggest you to go with BDD right from the word go. You really don’t need to worry about any tools just try to write tests that actually test behaviors. Once you get the hang of it, you can certainly start using some of the tools that help you automate your work and make you more efficient.
I will try to cover my personal toolset that I use to do BDD. Till then happy Behavior Driving