SpecFlow. BDD for the .NET world

Given you have an interest in Behaviour Driven Development (BDD)

And you’re the king of.NET

When setting up your BDD supporting framework

Then SpecFlow is for you

 

For clarity, the above is not “SpecFlow”, it is simply the Gherkin syntax used within the SpecFlow testing framework, which supports BDD. This same Gherkin syntax is also used in other BDD supporting frameworks such as Cucumber, Cucumber-jvm and JBehave.

 

Before diving in to SpecFlow, I feel it’s useful to have a quick paragraph on what Behaviour Driven Development is. Advanced apologies if this is teaching you how to suck eggs!

 

So here we go. https://en.wikipedia.org/wiki/Behavior-driven_development - Paragraph complete. That was a tough one.

 

So, what is SpecFlow

As stated earlier, SpecFlow is a .NET, BDD supporting test framework that allows us to write meaningful tests in plain English. When I say, “meaningful tests in plain English”, this refers to the BDD element, meaning tests written can be understood by everyone, no matter what your technical ability is. This is why BDD is so popular in an Agile world, as every member of the scrum team can read and understand what the tests are trying to achieve.

 

How does it work

I see SpecFlow being split down in to two areas (Feature Files & Step Definition), with both areas being split down even further.

 

Feature Files.

These always start with the story description E.g.

As a tester learning SpecFlow

I am going to write loads of Feature File scenarios for the Act. Consultancy website homepage

So I can become an expert in this chosen field

 

The purpose of these story descriptions is to provide a high-level overview of what your feature tests are trying to achieve.

 

Next you have your scenario E.g.

Scenario: For my first SpecFlow test, I am going to navigate to the Act. Consultancy website homepage.


This sets the tone for your individual test, while ensuring it keeps in-line with the overall objective of the feature. If you wanted to write a test for Act. Consultancy Blog page, this would form part of a brand-new Feature File dedicated to the Blog page. It would not form part of this Feature File which is dedicated for writing tests for the Homepage.

 

You would most likely have multiple scenarios for each Feature File (however, this may not always be the case) E.g.

Scenario: For my second SpecFlow test, I am going to review the content of the Act. Consultancy homepage.

Scenario: For my third SpecFlow test, I am going to confirm the partner information is displayed on the homepage

Scenario: For my fourth SpecFlow test, I am going to test whether each partner has a photograph on the Homepage.

And so on……

 

Finally, you have your scenario steps.

This is where you start to use the Gherkin Syntax of Given, When, Then (as exampled at the very beginning of this blog post).

 

The scenarios steps sit beneath each scenario and form the body of the test.

The Given step sets a past action, or the current state of a process (Given I have done xyz, or Given I am on webpage xyz)

The When step sets the action you’re about to take that will produce some sort of result (When I click on this submit button, or When I logout of this application)

The Then step is the assertion, confirming the result triggered by the When step. (Then I receive confirmation my application has been submitted, or, Then I am directed to a new screen containing text confirming I have logged out).

 

Of course, so far, the Feature Files scenarios I've been describing are of a basic level. SpecFlow is a powerful tool, and a lot of that power is contained within the Feature Files. They can be used to pass through table information, parameters and much more. I have added such examples in to a different blog post on the Accept.li website.

 

Now, on to Step Definitions.

 

Step Definition

This is where your "coding" commences.  Step Definitions have a direct link to the Feature Files. Not at the hierarchy Feature File level, but at the Scenario Steps. This allows for particular words, tables etc which form part of a Scenario Step, to be passed through to the Step Definition as a parameter, so it can then form part of the code to complete that Scenario Step.

 

When coding your Step Definition, it's best practice to continue to have BDD in your mind, this is because Step Definitions are not supposed to be code heavy. All the heavy code sits a layer or two lower, within Helper files. This adds extra benefit when it comes to the maintenance of your tests, as you may have multiple Step Definitions re-use the same helper file. Therefore, you’d only have to maintain that single helper file, rather than all the individual Step Definitions that use it.

I kind of see the Step Definition as an orchestration tool which pulls together all the test data and code required to achieve its desired results.

 

How does SpecFlow differ from Cucumber, Cucumber-jvm and JBehave.

The truth is, there is not much difference. Cucumber was designed for tests written in Ruby, Jbehave is designed for JAVA, and so is Cucumber-JVM, Specflow is a 'port' of Cucumber designed for .NET.

They all use the same Syntax of Gherkin. But, one noticeable difference is the way parameters are passed through to the Step Definition. e.g. SpecFlow shows (.*) where as JBehave shows $stringName

 

In conclusion

If you want to adopt BDD in a .Net world, then the powerful framework of SpecFlow is the way forward.