Introduction to Behavior Driven Development (BDD)

Behavior-driven development (BDD) is an Agile software development methodology in which an application is documented and designed around the behavior a user expects to experience when interacting with it. It is a product improvement process which advanced out of many sets of Agile practices & Test-Driven Development (TDD). BDD practice is based on using Ubiquitous language and Given-When-Then format to enable a highly collaborative process between the Three Amigos. 

The concept of BDD was introduced by Dan North, an experienced technology and organisational consultant based in London, as a means of clearing confusion between testers, developers, and business people.  

BDD Team Roles – The Three Amigos 

• Business Users are domain experts and understands application flows from a user’s point of view, so they provide user stories/specifications by example. This role can be shared with product owner and business owner
• Developer translates user story scenario into a function which is used to implement the steps to achieve the given acceptance criteria
• Test Automation QA’s are responsible for implementing each scenario using the BDD framework, according to the user stories that were created by the business users 

 Gherkin – The BDD Language 

Gherkin is a keyword-based, line-oriented language, identified by the GIVEN-WHEN-THEN pattern. This means that, except when you need to break sentences down into lines and use special reserved keywords, you are free to use actual ubiquitous (common understandable) language to write down behaviour examples. 

 Gherkin files are plain text Files and have the extension ‘.feature’. Each line that is not blank has to start with a Gherkin keyword, followed by any text you like. The keywords are:

• Feature
• Scenario
• Given, When, Then, And, But (Steps)
• Background
• Scenario Outline
• Examples
• """ (Doc Strings)
• | (Data Tables)
• @ (Tags)
• # (Comments)
• *

Gherkin is localized to 37+ spoken languages. 

Example of a Feature File: Login.feature

BDD Implementation

Each of these Given-When-Then steps are then transformed into executable code known as Step Definition. The entire scenario is tested by running the corresponding methods step by step.

Step Definition class example: LoginSteps.cs

BDD Process

• Behaviour Driven Development enables QA’s to create test scripts from both the developers' and the end client’s viewpoint
• End client define acceptance criteria which should pass in a given iteration
• These acceptance criteria enforce developers to write the application code to get the current test step to pass, before moving on to the next step
• This process gives a sense of gratification to developers every time a step execution passes
• By following this process Developers know with surety, which specifications work and are bug free

Need and Benefits of BDD Approach in Testing

Requirements might be misunderstood by each of the project team members. Based on this incorrect understanding, a faulty or buggy product is developed. It’s expected that the first step in every project is a discussion about the features, and behaviours of the software to be built.

Many teams using Scrum and other agile methods suffer following problems.

- Where to begin

- What is in and out of scope in testing

- The amount to test in one go

- What will be the test name?

- How to analyse failed test cases

BDD becomes a vehicle for communication between all the different roles in a software project due to its use of the concept of the ubiquitous language, hence presenting below listed benefits:

1. Improved Collaboration between Stakeholders
2. Efficient prioritisation: business-critical features are delivered first
3. Clarity on actual Business Requirements to be met
4. Business/User - centric design, hence High Business Value
5. Improved Traceability and Test Coverage
6. Smaller Feedback Loops, hence, Improved Delivery due to early discovery of unknowns
7. Living Documentation
8. Easily Maintainable scripts
9. Scenarios are Easy to Automate
10. Lower Costs
11. Enhanced Code Reusability

Drawbacks of using BDD Approach

• Time Overhead: Creating and maintaining the feature files and scenarios requires an overhead investment of time and effort. In short and/or small projects it may not be worth it, but in projects that have many iterations you’ll see a return on that investment.
• Retrofitting can be time-consuming: Retrospectively fitting BDD to an existing project can be a time-consuming and difficult process. Should you invest in creating BDD feature files and scenarios for legacy features, or should you just focus on what’s coming next?
• Communication: One of the biggest Pro of BDD is the biggest con also. Since proper communication is essential between the parties - user/client and the development team, misunderstanding or absence of any one of them, can cause the process to have ambiguities and lack of answers to the questions/doubts raised by either side.
• More time writing automation code: You will need to invest more time and effort in writing the automation code and keeping that code in sync with the steps defined in the BDD scenarios.
• Managing many feature files: The creation of many concise feature files can become a bit of a headache to manage. Good naming conventions and the organised use of tags helps, but things can easily get out of hand. It takes a degree of dedication and frequent refactoring to keep so many files organised and under control. There are several tools on the market, like HipTest, that help significantly with this.

While there are many success stories of teams that have implemented BDD, there are also many teams that have failed with BDD. More common, though, is that teams succeed and see the benefits to begin with, only to give up after several months. There are many ways to avoid this, but one important way is to understand the issues you’re likely to encounter before you encounter them. There’s no doubt though that the mindset shift that comes from following the BDD approach can pay significant dividends over time.

QA Best Practices for BDD Implementation

• Write declarative features: Scenarios should be written like a user would describe them
• Good Titles: Title of scenario or feature must communicate in one concise line what the behaviour is. Titles are often logged by the automation framework as well.
• Insert a narrative: Narratives describe in about one sentence what a feature or a scenario does.
• Avoid conjunctive steps: When you encounter a Cucumber step that contains two actions conjuncted with an “and”, you should probably break it into two steps.
• Reuse step definitions: This will improve the maintainability of your app: If you need to change a certain behaviour, you just need to change a single step definition.
• Use backgrounds wisely: If you use the same steps at the beginning of all scenarios of a feature, put them into the feature’s Background. Background steps are run before each scenario.
• Write Independent Scenarios and Features: A scenario should not be dependent on any other scenario or feature.
• Hiding Test Data in code
• Phrasing Steps: Write steps in third person
• Use Scenario Outline sections to cover multiple variations of the same behaviour, instead of multiple steps or scenarios. Gherkin does not have an “Or” step. When automated, every step is executed sequentially.
• Less Is Better: Scenarios should be short and sweet. It is frequently favoured that scenarios should content a single-digit step count (<10)
• Steps order must be Given-When-Then; no other order to be followed.
• Avoid UI action steps: Don’t write steps like ‘Click on Submit button’, etc.

Popular BDD Tools

For C# Platform, most commonly used BDD tools are listed below:

1. SpecFlow
2. NSpec
3. MSpec
4. BDDfy
5. ApprovalTests

Cucumber is the most popular BDD tools used for Selenium WebDriver Automation with Java.

---------------------------------------------------------------------------------------------------------------