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!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *