How To Install Specflow In Visual Studio 2017

By Edwin Hernandez

Howdy everyone. This time we would like to talk about BDD and SpecFlow. Nosotros have featured many types of test automation in this weblog, from UI Tests for regression to Performance Testing with JMeter. We have also highlighted some models to organize your tests such as POM (Page Object Model).

In this mail service, nosotros will first review from a concept standpoint, what is the BDD model and how to use it. Then nosotros will review what Cucumber is just similar a leg upward into a tutorial/intro of SpecFlow for .Internet.:

1. CONCEPTS

What is BDD?

Behavior-Driven Development (BDD) is an agile software development procedure that encourages collaboration among developers, quality assurance testers, and customer representatives in a software project. Information technology encourages teams to employ chat and concrete examples to formalize a shared understanding of how the application should comport (Wikipedia).

What this means is that BDD tries to link business requirements with technical specifications by writing requirements in plain English through something called Domain-Specific-Language (DSL).

A related concept is TDD, which is a methodology in which developers first write a Test, and only then do they write the code to make the test pass. It'south an iterative procedure in which more tests are created which and then results in more lawmaking or improvement to lawmaking.

BDD is an evolution of TDD. In BDD, behavioral specifications are written in manifestly English (DSL), and these specifications tin be used to write test lawmaking, and the test code can be used to create app code.

This doesn't always happen like this. As a thing of fact, on most of the projects of which I've been function, the BDD Feature is created first, then a developer writes some code to implement it, and only and then is a test written to validate the Feature. This is because I've mostly worked implementing API or UI testing, which is difficult to implement without a working UI or an API Swagger (only not incommunicable, you tin can just create stubs until endpoints are available).

Below is a sample Feature specification (also from Wikipedia). BDD practices tell u.s.a. that a feature must take a Championship, a Narrative, and Acceptance Criteria. Yous tin can have multiple scenarios for the same feature since you lot demand to cover several angles:

Title: Returns and exchanges go to inventory.

Every bit a store owner,
I desire to add items back to inventory when they are returned or exchanged,
and then that I can track inventory.

Scenario 1: Items returned for a refund should be added to inventory.
Given that a client previously bought a black sweater from me
and I have 3 black sweaters in inventory,
when they return the black sweater for a refund,
and so I should have four black sweaters in inventory.

Scenario 2: Exchanged items should be returned to inventory.
Given that a customer previously bought a blue garment from me
and I have 2 blue garments in inventory
and three black garments in inventory,
when they exchange the blue garment for a blackness garment,
and so I should have iii blue garments in inventory
and 2 black garments in inventory.

In one case a Characteristic is written, tests tin can be created. Each sentence on the specification is supposed to correspond to a unit of test code. These sentences can pass arguments down to the test lawmaking too (this is mostly washed with a test tool, more on this later).

It'south important to point out that BDD does not supercede TDD, it's an evolution of it. As well, BDD can have some overlap with other test design patterns/models, such as the ones we have covered in this blog like Page Object Model (POM), or Fluent Pattern Blueprint. But BDD works at a slightly college level than those blueprint patterns, it works at the requirement specification layer of the solution. This means that you can (and maybe should) implement BDD on top of a design model like POM.

BDD has been around for some fourth dimension (at least 2008-9), but it seems to take picked up in the early 2022s. BDD is however simply a methodology, some tools make information technology easier to implement it in a Programming IDE. We volition mention ii of them.

Cucumber

We will review what Cucumber is, just from a concept standpoint since there is already a tutorial in this web log that takes you lot step-by-pace on how to utilise it. You can observe it here: Get Started with Cucumber and Azure DevOps!

Having said that, Cucumber is an open up-source tool created to implement BDD. It was created in Blood-red and meant for Reddish testing. Nowadays information technology supports other languages such as Coffee and JavaScript. The open up-source version of Cucumber is called Cucumber Open up and can be found on GitHub. It seems to be supported by SmartBear who too owns a proprietary version called Cucumber Studio.

Cucumber implements Features files co-ordinate to the BDD standard and uses a line-oriented design to link the sentences (lines) in the Feature file to examination code. This arroyo is called Gherkin Language, a linguistic communication used in Cucumber to define test cases (feature files).

Delight check out the Cucumber Tutorial that is mentioned above for a step-past-step description on how to implement BDD with Cucumber using Eclipse for your IDE and even integrating your test solution with Azure DevOps.

SpecFlow

As y'all read this Microsoft Community weblog, you may be hither to learn how to implement all of this for .Cyberspace and on Microsoft'southward stack. Well, SpecFlow is the most popular (perhaps but ane?) open up-source BDD framework for .Internet.

SpecFlow started as a GitHub project in 2009 when a group of developers decided to build a native .Cyberspace framework to automate Gherkin feature files. This and then evolved into SpecFlow, which was funded by Tricentis in 2022.

Now, SpecFlow has swell documentation. If you are interested in this applied science, you should check out their Step by Step Getting Started Guide and their Blog.

In this serial of posts, we will provide a similar installation/utilise guide but try to provide added value by updating the steps for Visual Studio 2022 (official documentation nonetheless shows 2022) and past focusing a bit more on Microsoft's stack and Azure DevOps integration. We volition also try to bear witness you how to avert the normal bumps forth the way and investigate a few C# examples of usual cases where BDD is used in the .Net world.

In the next postal service, we will also explore Spex, another tool that makes information technology easier to sync your Characteristic files with Azure DevOps Test Cases.

Please read ahead!

2. TUTORIAL

Installing SpecFlow for Visual Studio 2022

Step 1. Installing Extension
- The setup starts by installing the SpecFlow Extension which will then install several item templates. For this, first Visual Studio 2022 without opening any project or lawmaking. Then from the top card, go to Extensions>Manage Extensions, then search the Marketplace for SpecFlow for Visual Studio 2022:
- Hit download and restart VS. When it comes back again, go through the dialog to install theextension:

Footstep 2: SpecFlow Projection Template
- Create a new projection. You will notice that new templates take been installed. Create a new SpecFlow Project (C#, Windows).
- Use Framework .NET half-dozen.0, cull MSTest for Test Framework, and make sure to add the FluentAssertions Library.
- The template will create a starter SpecFlow solution that should look like this:

You should now have everything y'all need to start writing Feature files. Let's review the methodology first.

Writing Feature following the BDD guidelines

Let's try to follow the complete BDD process, which as we said, is an evolution of TDD. We will try to now anchor it on Agile planning and later nosotros will integrate information technology with Azure DevOps.

- To simplify things, allow's piece of work with a simple Grade Library project that we will use to simulate ownership/selling stock.

- For this let'southward presume the following user story (tracked in e.1000., Azure DevOps):

As a StockApp User

I want to purchase a given corporeality of stock at the latest value

So that I can increase the value of my portfolio

Pace i. Let's write a SpecFlow Feature file with a unmarried scenario to test that story:

Please note that this case shows that you can use parameters in line, which volition then be replaced past the values in the Examples table. This is a quick and smart style to implement Data-Driven Testing. As well, note that nosotros are using the BDD keywords for Given, When, and Then to organize our narrative (And takes the value of the previous line). We are "translating" the user story into a BDD way Feature file with statements and validations to accomplish the acceptance criteria.

Step 2. Now comes the fun part, you tin right-click each of the lines on the Characteristic file individually or right-click any space to scope all lines, and "Define Steps". This will create step definitions for each line.

- This process should create arguments for your methods or every parameter you are using in your Characteristic file.

- You tin can choose to re-create the stride definitions to the clipboard or create a new class (.cs) already containing them

If you generate steps for all lines, it should look similar this:

Footstep three. Now, following the principles of TDD, nosotros accept a test, but we don't have the code to exam. Let's add a Grade Library project into the solution and reference it in the test project:

- At the Solution level, right-click then Add>New Project. Select a C# Course Library project, proper noun information technology and make sure to use .NET 6.0:

- Information technology should finish up looking something like this:

- Then make sure to reference the Class Library project in the Test Projection. Right-click References>Add together New Reference, then:

Pace 4. The next step would be to create the stubs of some empty classes, empty methods, and in general, just reorganize the arguments in the step definitions:

- Please annotation the apply of SpecFlow Fluent Assertions in this line:

newPortfolio.Value.Should().BeGreaterThan(initialPortfolioValue);

This is an assertion, fifty-fifty if we don't use the Affirm class. If the comparison fails, information technology should generate an Exception and neglect the examination. These fluent assertions are very useful and more than efficient at validating collections and objects with many properties for such cases as it is common for API Exam solutions.

- Now, the classes, methods, and properties mentioned in this test code don't exist in the Class Library projection nonetheless. If y'all used Visual Studio'southward feature that lets you create empty stubs with Non-Implemented Exceptions, then if yous run your test, they volition neglect of course. Let's move on to the side by side step.

Step 5. Following the TDD principles, allow'southward write some app lawmaking in the Class Library then that nosotros accept something to test:

That's just some uncomplicated app code that fits our purpose. Make sure your solution is built, so permit'southward move on to execute the tests.

Running SpecFlow Tests in Visual Studio

If yous have followed this tutorial downwards to this bespeak, you lot should exist good to go and open the Exam Explorer from the acme menu (Exam>Exam Explorer) and let it discover all tests. Information technology should look like this:

- Delight note that each line of Exam Information (Examples) is treated as a different test. Yous can execute a unmarried data set up, the whole test method, even the whole test class. Feel free to Debug and run line by line if yous are interested in seeing how the execution progresses.

- If you run all the tests, they should pass successfully:

That'southward it, y'all have your first passing SpecFlow tests. Non much data is provided, other than the fact that they passed and the elapsing. Now allow'south review how to ameliorate the reporting capabilities.

SpecFlow Reporting Capabilities

Reporting is a very useful adequacy of SpecFlow. This feature is similar to the Advanced Logger for UI Tests NuGet Package that we described how to implement in this blog but goes a few steps forward in that it provides a dashboard for your test run.

**Note: The way reporting was implemented before SpecFlow iii was that Reporting was included within the SpecFlow framework and package. All the same, these reports have been deprecated forth with the whole SpecFlow-Runner (check the proclamation here). Those reports were as well helpful and If yous are interested in how these SpecFlow 2 reports used to work, check the documentation here. However, I think that the new reports are just every bit good, if not amend.

The new way to go, starting on SpecFlow iii, is to employ SpecFlow LivingDoc. This is a separate NuGet package that you should already accept installed in your solution since yous are using the SpecFlow Projection Template:

SpecFlow LivingDoc tin can help you generate reports for Azure DevOps or locally. For now, let'south review how to create a report locally:

Pace 1. Build (and clean) your project.

Step 2. Execute all tests.

A file named TestExecution.json should have been created in this location:

<SolutionDirectory>\<TestProject>\bin\Debug\net6.0

Footstep 3. The HTML written report tin can simply be generated through Control Line (CLI). You will need SpecFlow LivingDoc CLI, merely do NOT install the one from NuGet Packages. Instead, open the Bundle Managing director Console and execute this:

dotnet tool install --global SpecFlow.Plus.LivingDoc.CLI

That should install the version that is uniform with your SDK (.NET vi.0).

Step four. From the aforementioned Parcel Manager Console, execute LivingDoc by providing the folder of your test project and the location of the TestExecution.json file:

LivingDoc feature-folder C:\users\<yourUser>\source\repos\BlogDemo\BlogDemo -t C:\users\<yourUser>\source\repos\BlogDemo\BlogDemo\bin\debug\net6.0\TestExecution.json

That should generate an HTML file like this ane:

- I find this report very useful because it includes every information set, all stride definitions, scenario, and Feature descriptions and it is easy to filter. You can run this report for full execution of all the features of your application and it should include all in a single report/dashboard.

- Make sure to check out the Analytics tab, to find the summarization (i.e., dashboard) view: