Getting Started with Behavior Driven Development

Behavior Driven Development (BDD) is an agile software development practice – introduced by Dan North in 2006 – that encourages collaboration between everyone involved in developing software: developers, testers, and business representatives such as product owners or business analysts.

BDD aims to create a shared understanding of how an application should behave by discovering new features based on concrete examples. Key examples are then formalized with natural language following a Given/When/Then structure. 

Gherkin is the most commonly used syntax for describing examples with Given/When/Then in plain text files, called feature files. Gherkin scenarios can be automated to validate the expected behavior. At this point, BDD tools – such as SpecFlow – come in handy. Automated acceptance tests, however, are an optional by-product of using BDD, not the sole purpose.

Automated Gherkin scenarios are “green” when up-to-date and in sync with system behavior. Whenever the updated system stops producing the expected behavior, the affected scenario turns red to alert the team. This failure can be caused by new behavior that contradicts with previous requirements or the updates introducing unwanted side-effects. In any case, the team must fix this mismatch to make all scenarios green again. When the team follows this practice, Gherkin documentation grows with the system, providing an always up-to-date specification of its behavior. This is also called “Living Documentation”, here you can view an example.

To summarize, Behavior Driven Development can be defined as follows:

BDD is an agile software engineering practice that supports feature discovery and encourages collaboration among developers, testers and business participants in a software development team. BDD is facilitated through examples expressed in natural-language constructs expressing the expected system behavior, and automation validating these examples as acceptance tests.

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, 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. Think of a BDD scenario like a bug report that is written in natural-language and posted before the system has been implemented. It describes the steps to reproduce (Given/When) and expected outcome (Then) without the symptoms (unwanted behavior) that usually triggered the bug report.
• 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. Here you can view an example.
• 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. More frequent, high quality releases enable rapid response to evolving user needs and dynamic market pressuress.
• 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.

Many teams using Behavior Driven Development turn these concrete examples/specifications into automated acceptance tests. At this point, BDD tools and testing frameworks – such as SpecFlow – come into play.

What is SpecFlow?

SpecFlow is the #1 .NET open source framework for Behavior Driven Development, Acceptance Test Driven Development and Specification by Example. With over 10 million downloads on NuGet, SpecFlow is trusted by teams around the world.

In SpecFlow, specifications are written in plain, simple language which is defined by the Gherkin Syntax (Given-When-Then).

How does SpecFlow support BDD?

SpecFlow supports BDD by providing a mechanism to turn specifications into executable code. This code can then be used to create automated tests that run against the application to verify whether it actually exhibits the behavior described in your specifications.

To put it in BDD and SpecFlow terms, SpecFlow turns the Gherkin Given / When / Then syntax scenarios in feature files into executable code methods known as step definitions.

Transforming these steps, expressed in natural, readable language, into executable code, is where SpecFlow’s responsibility of ends. To further implement your test automation so that it actually communicates with your application under test, you will need to add other tools to your test automation solution.

Some tools that are often used in combination with SpecFlow to form a test automation framework are:

• A unit testing framework such as NUnit, MSTest or xUnit.NET. This unit testing framework typically performs three tasks:
  – Act as a test runner that executes the scenarios one by one, or in parallel.
  – Provide an assertion library that can be used to compare expected outcomes that are codified by the creator of the test automation with actual outcomes observed in the application under test.
  – Provide basic test results in reports, mostly in a form that can be picked up by a test orchestration or Continuous Integration tool like Azure DevOps, Jenkins, TeamCity or similar.
• A library that interacts with browsers and browser applications. The most common example of these tools is the Selenium WebDriver library.
• A library that interacts with APIs or web services, for example RestSharp.
• A library that generates human-readable reports, often in HTML format. Two popular examples of this category of tools are Allure and ExtentReports.

Get started with BDD & the SpecFlow ecosystem

SpecFlow provides a whole ecosystem of tools to use BDD on Azure DevOps and the Microsoft .NET platform. Besides SpecFlow and SpecFlow+Runner, there is also a SpecFlow Visual Studio Extension that provides a Gherkin editor and build integration.

SpecMap and SpecFlow+LivingDoc are Azure DevOps extensions that support the team in the overall BDD process with managing their backlog using story maps and accessing their living documentation.

SpecFlow+ LivingDoc is also available as a set of plugins and tools for SpecFlow to generate local or self-hosted documentation out of your Gherkin feature files, which can be easily shared with your team and stakeholders without the need for Visual Studio or Azure DevOps.

💡 Demo: Try out our SpecFlow+ LivingDoc Generator Demo which is hosted on GitHub Pages.

To utilize SpecFlow with its powerful ecosystem, we recommend checking out the following extensions and getting started information.

1. The comprehensive getting started & installation guide for SpecFlow
2. SpecFlow+ Runner: A dedicated test runner for SpecFlow and integrates directly with Visual Studio.
3. SpecFlow+ LivingDoc: An/Azure DevOps (VSTS) extension that takes your Gherkin feature files and renders them in an easily readable format with syntax highlighting.
4. SpecFlow+ LivingDoc Generator: A set of plugins and tools for SpecFlow to generate local or self-hosted documentation out of your Gherkin feature files, which can be easily shared with your team and stakeholders without the need for Visual Studio or Azure DevOps.
5. SpecMap: An Azure DevOps (VSTS) extension for story mapping.