_edited_edited.png)
Behavior-driven development was invented well over a decade ago. Back then, a lot of teams were starting to adopt test-driven development. However, as is common when you get a lot of smart techy people together, these teams were starting to lose sight of the actual aim. Passing the test began to take precedence over producing good software.
Business-Driven Development (BDD) is a testing approach derived from the Test-Driven Development (TDD) methodology. In BDD, tests are mainly based on systems behavior. This approach defines various ways to develop a feature based on its behavior.
Behavior Driven Development (BDD) is an agile software development practice that encourages collaboration between everyone involved in developing software: developers, testers, and business representatives such as product owners or business analysts.
BDD describes application behavior from a user’s point of view. Overall, the main goal of BDD is to improve the collaboration between all stakeholders involved in developing software and form a shared understanding among them.
So Basically, BDD is an approach to understand the behavior of a feature that is to be developed in a plain and simple text. When BDD was invented, the only way to do something like this was to create a domain specific Language. The result was Gherkin, a formal language for capturing software requirements.
Gherkin overview
Gherkin is a language, which is used to write Features, Scenarios, and Steps. The purpose of Gherkin is to help us write concrete requirements.
To understand what we mean by concrete requirements, consider the following example −
Customers should be prevented from entering invalid credit card details.
Versus
If a customer enters a credit card number that is not exactly 16 digits long, when they try to submit the form, it should be redisplayed with an error message advising them of the correct number of digits.
The latter has no ambiguity and avoids errors and is much more testable.
Gherkin format follows a simple Given--When--Then steps to understand the behavior of any feature that is to be developed where,
Given - Describes the preconditions and initial state before the start of a test and allows for any pre-test setup that may occur
When - Describes actions taken by a user during a test
Then - Describes the outcome resulting from actions taken in the When clause
Occasionally, the combination of Given-When-Then uses other keywords to define conjunctions
And - Logical and
But - Logically the same as And, but used in the negative form
Example
Scenario − Withdraw money from account.
Given I have $100 in my account.
When I request $20.
Then $20 should be dispensed.
If there are multiple Given or When steps underneath each other, you can use And or But. They allow you to specify scenarios in detail.
Example
Scenario − Attempt withdrawal using stolen card.
Given I have $100 in my account.
But my card is invalid.
When I request $50.
Then my card should not be returned.
And I should be told to contact the bank.
So, why use BDD?
Here are some of the top advantages that teams practicing BDD experience:
Reduced Rework / Shared Understanding: Concrete examples of expected system behavior foster a shared understanding by being specific enough for developers and testers while still making sense to business participants.
Faster Feedback: Example scenarios describe focused, granular changes to the system under development. This enables teams to evolve the system in small steps while keeping it potentially shippable, allowing for shorter release cycles and faster feedback.
Effectiveness: Since you extend the system in small increments, you can validate business value earlier and avoid unnecessary features. This prevents gold-plating and makes the overall implementation of the system more effective.
Lower Cost: Driving automated acceptance tests through test-first BDD scenarios is much cheaper than post-automating acceptance tests. Teams practicing ATDD (Acceptance Test Driven Development) use their shared understanding to develop the feature and the test automation, while teams separating development and test automation need to interpret and fine-tune scenarios multiple times. This causes extra effort and can lead to misaligned interpretations. Additionally, test automation based on scenarios that were used to drive the implementation have a better focus and more relevant assertions. This leads to higher test automation coverage and more relevant test automation scenarios, which reduces regression errors and efforts for manual checks.
Single Source of Truth: Specification through examples that is guarded with automated acceptance tests is an always-up-to-date description of the current system behavior (“Living Documentation”). This provides a single source of truth for the team, business stakeholders and important external parties like regulatory authorities or partners relying on the system specification.
User Satisfaction: By focusing on the needs of the business, you get satisfied users — which translates to customer loyalty and better business outcomes. The higher degree of test automation frees more time for manual exploratory testing and yields less errors in production, especially when shipping new versions at a high cadence.
Code Quality: Using Acceptance Test Driven Development has a positive impact on code quality: it promotes emergent design that ensures loosely-coupled, highly-cohesive architecture and avoids over-engineering and technical debt. This ensures that a system stays testable and maintainable– and that it can be quickly changed to support new requirements without sacrificing stability.