Behaviour Driven Development
Behaviour Driven Development
As the name suggests, BDD is a method of development where an application is designed and developed by describing its behavior to an outside user. It is focussed on the business behavior of our code. Simply, the “why” behind the code. BDD emerged from Test Driven Development (TDD).
We have business needs and developer tasks. The developer will list the tasks based on business needs. So, that way we can understand the behavior of the system while adding a new feature.
Behavior Driven Development is an agile software development technique developed by Dan North. According to him, it will encourage teams to deliver the software that matters by emphasizing the interactions between stakeholders.
In Waterfall model for software development, the testing phase will appear at the end of development phase. It will provide a flow, but it may result in a large number of feedback loops and wastage of time. We spend most of the time for developing the wrong requirement.
BDD is actually based on Test Driven Development. Uses the ideas and general techniques of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development. So that it will give an idea about how software development should be managed by business interests and technical insight. It will use specialized tools for development.
The first step for BDD is making a goal. A goal that will translate into features and stories. To make sure that the whole team understands what’s wanted, we describe the behavior in non-technical language. We’re careful to use names that reflect the ubiquitous language used by business people.
A real world example for BDD,
Given baby pigs cost $10
When we sell Asha the Baby Pig
Then the customer should be charged $10
That is,
Given a context
When an event happens
Then an outcome should occur.
This is the outcome of BDD. Whatever a developer write must go into Given-When-Then. A general tendency of developers like me is to write tests later. Because most of the time it will eat a large amount of time. BDD makes the entire testing process easy for a developer. Isn’t the above example easy to write read and understand? It is also like writing the documentation for the functionality.
Cucumber tools support BDD. It offers a way to write tests that anybody can understand, regardless of their technical knowledge. Cucumber’s language, Gherkin, is usable in a growing variety of human languages, including LOLZ.
The fact is it is not a replacement for RSpec, test/unit, etc. Also not a low-level testing/specification framework.
Features
Feature is something that your software does (or should do) and generally corresponds to a user story and a way to tell when it’s finished and that it works.
A general format is,
Feature : < short description >
< story >
< scenario 1 >
….
< scenario n>
It’s just an example, you can use any format for this. It focused on
1. Who’s using the system?
2. What are they doing?
3. Why do they care?
A feature is defined by one or more scenarios. A scenario is a sequence of steps through the feature that exercises one path. Cucumber uses the BDD style that Dan North put forth, given-when-then.
Given – Sets up preconditions for the scenario, much like before-blocks in RSpec.
When – Contains information about what feature talking about. The actual behavior.
Then – Checks the post conditions.
There are no constraints on the number of order of tests. It is generally best to keep scenarios simple as possible.
Benefits Of BDD
1. Granularity of requirements: – It will help to create a set of fine-grained requirements, and that leads to a lot of discussion about the specific requirement from the very beginning.
2. Saves time and resources: – The clear cut plan over the requirements will help to reduce time wastage by developers.
3. Less costly feature development: – Since BDD is based on ‘behavior’ of the system the acceptance criteria is executable so it will reduce time and confusion.
In fact, Behavior-driven development is a set of best practices that advise you on how to develop software by centering your users. In the past software development was mainly about technical solutions. This has changed! Behavior-driven development focuses on the purpose of your work to people who will use it. This way you will create better software and successfully address your customers’ needs. Will introduce a few tools for Behavior-driven development. Stay tuned!
Talk to our IT Professionals
Other Blogs:
- Share this
