XUnit: Run your Web Api integration tests in strict order with ITestCaseOrderer

In some scenarios, we might wan’t to run strictly ordered integrations tests to be sure a complex process with several Web Api calls success.
One example could be register a fixture created user, log in with the account, update it’s profile data y and finally delete it.

This four actions should be evaluated individually, but we may need chaining them in strict order because the next test needs to be fed with the previous execution output result. A good example could be controller actions that are decorated with [Authorize] and need the authorization header to be set, so we must log the recently registered user to proceed.

Since Version 2.0, XUnit provide us with some interfaces and decorators that allow us to perform this test case ordering. In this post we are going to show the usage of ITestCaseOrderer interface and Owin Test Server alltogether.

We are going to code some extensions methods as well to code cleaner facts when using Owin RequestBuilder fluent api.

Let’s start by creating three [Facts] in a class:

 

The first fact, will create a Register user request to the Web Api and will store the register output in static context (XUnit creates a new instance of the class whenever a new fact is executed so we need to keep the result).

 

The second fact, will update the user profile, which is an Authorized action, so we have to log the user in the api and recover its authorization header to chain will the next api call. We are also recovering data from registerItem variable stored in the previous test, and setting some user data to be updated:

 

The third fact will recover the logged user information from the backend, that is an authorized action as well, and It will use the variable userDataRequest from the previous fact.

 

RequestBuilder  Fluent Api Extension

 

Now it is time to create our implementation of ITestCaseOrderer to implement our own specs ordering logic:

The first of all, we are going to create a custom attribute that we will use to decorate our facts with the desired order:

 

 

With the custom attribute in place lets implement the Test Case Orderer:

 

The ITestCaseOrderer receives the Test Cases that are declared as Fact in the class decorated with the orderer implementation.
the ITestCase interface is heavily based on abstractions so we should not use standard reflection and must use the interface of XUnit.Abstractions.IMethodInfo to extract the priority value of the TestPrioriry attributes. We use a SortedDictionary to add the priority/TestCase key value and we return them sorted.
Now, we just need to decorate our class to implement the Orderer and decorate the methods with our TestPriority attribute and the desired order so XUnit will run the facts in strict order.

 

 

And that is all for today!. Happy Coding!

Asp.net Core with SignalR server and Autofac

SignalR server for asp.net core is currently in version 0.2.0. It has not been released yet to the official nuget repositories, so we must configure our project to use the asp.net core dev feed to obtain SignalR related packages.
Autofac for asp.net core still does not have the hubs registration extensions that we are used to when using full framework packages, but we will see how we can write them from scratch.

First of all we create a new asp.net core web project and we create a NuGet.config file so we can specify the core devevelopment NuGet feed so we can restore the websockets and SignalR packages.

The NuGet.config file should look like this:

Once created the nuget file, we should add the dependencies to project.json. The dependencies to use SignalR and autofac are shown below:

 

We are now set to start configuring our hubs!. As an example we are going to create a ChatHub that will receive a service to keep track of connections in it’s constructor.

Let’s create first the service interface and implementation to register it with AutoFac:
IHubTrackingService.cs

 

HubTrackingService.cs

 

The HubTrack class is a POCO class with the following properties, just as an example:
HubTrack.cs

 

Now we are ready to create our ChatHub injecting in the constructor the HubTrackingService to allow tracking clients with OnConnected Method:

ChatHub.cs

 

Now, it is time to configure our Startup.cs to add SignalR Server and dependency injection.
In full framework, we use the RegisterHubs autofac extesion to register our hub classes:

but it is not available yet in Autofac for asp.net core so we should write a ContainerBuilder Extension to do this for us, the code is shown below:

AutofacExtensions.cs

Note: We use ExternallyOwned() to allow SignalR disposing the Hubs instead of being managed by Autofac.

Once our extension is added to the project we should set our Configure and ConfigureServices methods in Startup.cs

 

Startup.cs

Notice the line:

 

In asp.net core we don’t have Assembly.GetExecutingAssembly() so we get the assembly from the Startup.cs type
How do we use the Hubs to notify clients when execution is inside a Mvc/Api Controller? Continue reading “Asp.net Core with SignalR server and Autofac”