BDD (Behaviour-Driven Development) is an agile development technique which encourages collaboration between Business, Dev and QA. BDD first coined in 2009 by Dan North. It is an extensive approach of Test Driven Development, Acceptance Test-Driven Approach, and Domain Driven Design to snag down their drawbacks.
BDD came in to picture since requirements are often interpreted differently by teams. It leads loss of time in back and forth communication while refining the exact requirements. So as to save complexity in process BDD evolved and currently many organizations have adopted it.
BDD adopts three basic principles:
- Enough is enough: The sufficient amount of time should be taken for planning, development, and testing.
- Delivering value with quality: Shooting in the dark does not make sense as it hampers client, stakeholders, and users at the same time. So, proper analysis of requirements is a thumb up which BDD follows.
- Behavior is the crux: Focuses more on behavior of product that will lead to better delivery and happy customers.
BDD (Behaviour-Driven Development) can be implemented using Gherkin language with BDD tool. Some of the widely used tools which BDD supports are Specflow in C#, Cucumber in Ruby, Freshen in PHP, and Jbehave is in Java.
A question may arise in your mind what is Gherkin? Everything needs a representation so does BDD, hence a form of representation Gherkin is introduced which is easy to understand domain-specific language or simply layman’s language. It defines the structure and syntax of the tests. Moreover, it also supports over 40 languages which boost documentation as well as test cases.
Gherkin Source file format has ‘.feature’ the extension which is commonly known as Feature file. Feature file is so simple which everybody across the board (developer, tester, BA and business) can understand. This feature file contains a list of independent scenarios, written using keywords like Given, When, Then etc. Mapping of requirement with scenarios is done using Feature file.
Now, the next step is binding these readable specifications to machine language which is achieved by using any BDD tool Specflow, Cucumber, etc. These tools convert human readable format into machine code.
How BDD works?
BA/ SME create Feature files in domain specific language then Feature and Scenarios are agreed by Dev, BA and QAE teams. Dev develops code for the same scenarios and QA creates BDD tests using tools and framework. These tests are run as a part of Continuous Integration for every build and finally, it is shared with the entire Sprint team.
Implementation of BDD using Specflow
As described above User Story are the requirements that are tied together. The User story is a scenario where an object performs an activity and end results or state of the activity are validated and tested later.
Once client or stakeholders are done with the requirements, it is converted into Feature files using Gherkin. Feature file is the entry point of the tests which works as the script as well as document. It may contain a scenario or a list of scenarios.
Gherkin has below-mentioned components that are used while writing the executable Scenarios:
- When, And, Then, but
- Scenario Outline
Later these Scenarios as converted into Step Definition using Specflow and Selenium. Every line in Feature file transforms into methods and code can be developed using Selenium and C# (depending on what BDD tool is being used). All together when enough Scenarios are covered, it is considered as deployed for all the Sprint teams.
Along with these positive aspects, BDD (Behaviour-Driven Development) holds some downside too. The primary downside is if any requirement is the unclear and User/Client not available to discuss then it becomes difficult to work with unclear feature. Also, clarification among teams consumes a lot of time every so often. On the first side BDD nails down all the leaps in the dark ensuring more successive approach, leveraging it many firms are boosting their client list and projects.