Introduction

Automated testing using Specflow is an efficient way to provide test coverage to secured/non-secured services. The article will show how to write testing Scenarios that target a nonsecured WebAPI service.

Prerequisites

You need to have basic knowledge of Web API.

You can see an initial introduction regarding setting up Specflow following this link.

The Solution

PropertiesAPI is a WebAPI service that exposes CRUD endpoints to manage Properties

According to this endpoint, we request results with pagination. The pagination should be returned as a response header "X-Pagination".

PART II: Feature File

The Properties.Feature file lists all the Scenarios. Each Scenario, in the feature file, tests an endpoint in the PropertiesAPI:

The Add Property that targets the POSTrequest of the PropertiesAPI:

The Update Properties scenario will target the PUTrequest for updating properties:

The order of the steps assumes that before we update a Property, the first step is to create one. The first step Given I create a new property can be considered as a common step to be reused by the other scenarios.

The Delete Properties scenario will target the DELETErequest for deleting a property:

EnableEtag Attribute

One of the endpoints has been decorated with EnableEtag attribute. ETag is a unique key (string) generated at the server for a particular resource. The next time the client requests the same resource, the server will return 304 and with the key added to the Header of the response. To put it in simple words, the server tells the Client "You can use what you already have since it has not been updated".

We want to test whether the following flow works:

The server will generate a Key and add it to the response. However, as it is the first time we are using this endpoint, it will respond with 200.

Next time, the client requests the same resource, if the response has not been updated and the time expiry of the cache is within the limits we defined (current ETag implementation is using web caching), then the server will respond with 304.

The Get Properties Scenario will target the GETrequest for retrieving properties with pagination:

The first step in the Update Properties Scenario is the same as the first step in the Add Property and Delete Property Scenario. We shouldn't rewrite the same step for other scenarios, but instead we can reuse them as common steps. We should try to create reusable steps that can serve as many scenarios as possible. The more reusable steps we have, the easier and faster it will be, to design scenarios that aim to test various cases in our code.

One more reusable step is GivenIRequestToViewPropertiesWithPagination. However, this step is not called only by WHEN Steps , but also by Given and Then steps. We need to notify the framework that this is a common step, by decorating it with the following attributes:

Thank you very much for the awesome "Using Specflow to test Web API - PART 1" article, When are you publishing the part 2 article, If not soon please send the code to my mail id pentanareshkumar@gmail.com

Hi Veronica, i was impressed by the idea of using the spec flow as a testing framework for the web api.
Could you share with me the code for the Part 2 so i can understand how it works together?
my email is: vysotsky.artem@gmail.com

Many thanks for taking the time to check the solution. You don't need to deploy it. Just start the Web API and then run the tests. The tests are a separate project but part of this solution. However, you can also decouple this project. It does not have to be part of the solution.

I know that the ETAG test fails. I broke it couple of days ago.. I will fix it at some point today and redeploy. Normally, the Acceptance tests project should not be part of the solution. Ideally, QA should use it and target all the endpoints of the resource server. It's using Restsharp for rest calls, so basically no reference is required. You can also configure fiddler, to monitor all the requests you make from Specflow.