How does SpecFlow support BDD?

How does SpecFlow support BDD?

Sławomir Bijak
Sławomir Bijak
February 10, 2021  | 4 min read

SpecFlow is the perfect tool to work with when using Behaviour Driven Development (BDD). But exactly how does it support BDD?

There are many approaches, styles, or philosophies in IT. To mention just a few:

  • Design by Contract (DBC)
  • Test-driven Development (TDD)
  • Model-driven Development (MDD)
  • Feature-driven Development (FDD)

And, of course, Behaviour Driven Development (BDD), described in this article.

BDD is a great add-on to TDD or ATDD. Why?

  1. Because BDD helps to run effective conversations in a development team.
  2. Because the approach uses simple language and has a shallow learning curve.
  3. Because it automates technical and end-user documentation with some tools, among which there is SpecFlow.

But let us make a step back and explain everything.


What is BDD? Basics

Behaviour Driven Development (BDD) by definition, is an agile software development practice based on close cooperation between people interested in products and participating in its creating: product owners, business analysts, testers, developers.

Yes, it sounds general…

That is why, what really allowed me to understand what the BDD exactly is, is the other name of this practice: Specification by Example.

BDD aims to create a common understanding of how an application is supposed to function (this is specification). This knowledge and understanding are achieved by discovering the functionality of the application through concrete examples.

Collaboration _ understanding _ automated acceptance tests _ living documentation

I hope with this graph you will understand the process.

But let’s get into details.


BDD and Three Amigos

The first stage of the process is Specification by Example workshop, also known as Discovery or Deliberate Discovery.

This stage helps to formulate software requirements through examples of behaviour. The Discovery should be collaborative and occur in a group of Three Amigos.

What is the Three Amigos group?

It is a mix of different perspectives of people who are involved in the project. The number of three is conventional and is based on a standard number of sides of the project's contributors:

  1. Business side - perspective considering what problem is trying to be solved by a product.

    What is the business value that should be provided?

  2. Developer side - perspective considering how technically the product should be built?

    What kind of constraints are there?

  3. Testing side - perspective considering edge-cases and exceptions.

    What could additionally happen? What unobvious use-cases should be handled?

As I mentioned earlier, the number of sides is only conventional. In some projects security or UX roles are necessary and should be included.

However, the number of points of view must not be oversized because it could be paralysing. If necessary, it is possible to split the large team into a couple of smaller ones.

The Three Amigos are brainstorming and exploring domain by What happens, if... questions. This exploring gives new knowledge about the domain and brings new additional rules.

That rules are acceptance criteria.

In the next stages, the reached common understanding is formalised into organised scenarios are then turned into automated acceptance tests.

All these automated acceptance tests build up an actual description of the application's behaviour, also known as Living Documentation.


What is SpecFlow?

SpecFlow is an open-source .NET framework for BDD. It has almost 17 000 000 total downloads from NuGet package gallery. These statistics make SpecFlow popular and often selected by teams around the world.

The tool helps to formulate scenarios in language that is understandable for non-technical staff as well.


BDD and SpecFlow – advantages

The main advantage of SpecFlow in Behaviour Driven Development is shortening the time needed to create all the steps in the process.

What do I mean?

Scenarios lay the foundations for automated acceptance tests generation. And tests are the base for generated Living Documentation.

Furthermore, the framework generates several helpful reports and charts.

  • Test Execution Report with Test Timeline Summary, Test Result View and Features or Error Summaries presented in tables.
    specflow bdd 1-1
  • Living Documentation is presenting data in the form of an interactive table, easy to filter. Graphic design makes the interpretation of information easy.
  • Analytics Report that is a part of Living Documentation presents acceptance tests results by circle diagrams.

SpecFlow and BDD. Scenarios creation

At the stage of formulating the specification by example, SpecFlow allows creating scenarios in natural language by means of Gherkin syntax.

Gherkin syntax permits to express scenarios in Given-When-Then template then put into plain text files with .feature extension.



Feature: Book details 

As a potential customer 

I want to see the details of a book 

So that I can better decide to buy it. 



Given the following books 

| Author        | Title                              | Price | 

| Martin Fowler | Analysis Patterns                  | 50.20 | 

| Eric Evans    | Domain Driven Design               | 46.34 | 

| Ted Pattison  | Inside Windows SharePoint Services | 31.49 | 

| Gojko Adzic   | Bridging the Communication Gap     | 24.75 | 



Scenario: The author, the title and the price of a book can be seen 

When I open the details of 'Analysis Patterns' 

Then the book details should show 

| Author        | Title             | Price | 

| Martin Fowler | Analysis Patterns | 50.20 | 

Source: GitHub

As you can read above, the Gherkin syntax facilitates systematisation of scenarios within a feature. It allows extracting common steps for all scenarios put as Background.

All tags and the feature's description are helpful and visible in the generated documentation.

SpecFlow supports table and multiline string parameters. Due to this, the feature files are clearer.

All steps within scenarios are bound to their definitions in code files.

It is possible to introduce a driver pattern as a middle layer between step definition and automated code.

[Given(@"the following books")] 

public void GivenTheFollowingBooks(Table givenBooks) 





[When(@"I open the details of '(.*)'")] 

public void WhenIOpenTheDetailsOfBook(string bookTitle) 





[Then(@"the book details should show")] 

public void ThenTheBookDetailsShouldShow(Table expectedBookDetails) 




Source: GitHub


SpecFlow and BDD. Automated acceptance tests supported

Based on scenarios and step definitions, SpecFlow generates acceptance tests.

One can say that SpecFlow turns specification into code. This code is useful for continuous verification that actual behaviour is appropriate and consistent with expectations.

Once tests are run, one can look at a log and report files to be more familiar with results:

  • which tests passed,
  • which failed
  • and why.

In addition, the report file is in HTML format, thus it is easy to read and user-friendly.

specflow bdd 2-1

Figure 1. Example of Execution Details in Test Execution Report

Sometimes verification of acceptance criteria requires UI behaviour testing. With SpecFlow, it is easy to turn Selenium driver on for acceptance tests.


SpecFlow and BDD. Living Documentation supported

SpecFlow provides LivingDoc plugin that allows you to generate using CLI Living Documentation in HTML format - excluding or including tests results.

As a result, you obtain a complete set of scenarios that lays foundation for automated acceptance tests, which in turn result in a constantly updated specification of behaviour - a reliable source of knowledge about the solution.

For teams working on Azure DevOps platform, SpecFlow provides an extension to build and share Living Documentation in this environment.

specflow bdd 3-1

Figure 2. Generated Living Documentation

specflow bdd 4-1

Figure 3. Analytics section in Living Documentation


The summary

Of course, using SpecFlow does not mean that the team uses BDD confidently. But this tool will be helpful to achieve, e.g.:

  • better understanding for the entire team - by examples formulated by means of natural language. Better understanding indicates reduced reworking;
  • current documentation - thanks to a set of automated acceptance tests that describe a solution's behaviour and can be a single source of truth for the team;
  • user satisfaction - by focusing on business value and user stories that translate to customer loyalty and better company outcomes.