ASP.NET Web API Integration Testing with One Line of Code
Rate this post

A very popular post about integration testing ASP.NET Web API was published quite some time ago. However, since then, OWIN has been released. OWIN makes integration testing ASP.NET Web API much simpler. This post describes what is required to set an OWIN-based integration testing framework up.

This, believe it or not, only requires a single line of code with OWIN self-hosting! It assumes that your web API project is powered by ASP.NET Web API 2.2 with OWIN.

The basic idea behind this particular approach is that the integration test project self-hosts the web API project. Consequently, the integration tests are executed against the self-hosted web app. In order to achieve this, the web API project must be modified a little bit. Fortunately, this is easy with OWIN.

A web app powered by OWIN has two entry points: Application_Start() and Startup.Configuration(IAppBuilder). There isn’t a big difference between the entry points but it is important to know that Startup.Configuration is invoked a bit later than Application_Start().

So the integration test project can self-host the web API project, all web API initialization logic must be moved to Startup.Configuration(IAppBuilder) as follows:

public partial class Startup
    public void Configuration(IAppBuilder app)
        var configuration = new HttpConfiguration();
        // Execute any other ASP.NET Web API-related initialization, i.e. IoC, authentication, logging, mapping, DB, etc.

Not much is left in the old Application_Start() method:

public class WebApiApplication : HttpApplication
    protected void Application_Start()

Now, in order to test your web API project, add the following OWIN NuGet packages to your tests project:

PM> Install-Package Microsoft.Owin.Hosting
PM> Install-Package Microsoft.Owin.Host.HttpListener

Following is the single line of code that is required to self-host your web API project:

using (var webApp = WebApp.Start<Startup>("http://*:9443/"))
    // Execute test against the web API.

That single line starts the web API up.

It is better that this is set up once for all integration tests for your tests project using MSTest’s AssemblyInitialize attribute as follows:

public class WebApiTests
    private static IDisposable _webApp;

    public static void SetUp(TestContext context)
        _webApp = WebApp.Start<Startup>("http://*:9443/");

    public static void TearDown()

Now, the test code for testing a web API, which is self-hosted at localhost:9443 and protected using token-based authentication, can be written as follows:

public async Task TestMethod()
    using (var httpClient = new HttpClient())
        var accessToken = GetAccessToken();
        httpClient.DefaultRequestHeaders.Authorization =
            new AuthenticationHeaderValue("Bearer", accessToken);
        var requestUri = new Uri("http://localhost:9443/api/values");
        await httpClient.GetStringAsync(requestUri);

The above approach has a wide range of advantages:

  • You don’t have to deploy the web API project
  • The test and web API code run in the same process
  • Breakpoints can be added to the web API code.
  • The entire ASP.NET pipeline can be tested with routing, filters, configuration, etc.
  • Any web API dependencies that will otherwise be injected from a DI container, can be faked from the test code
  • Tests are quick to run!

On the other hand, there are a few limitations, since there are different behaviours between IIS hosting and self hosting. For example, HttpContext.Current is null, when the web API is self-hosted. Any asynchronous code might also result in deadlocks when it runs in IIS while it runs fine in the self-hosted web app. There are also complexities with setting the SSL certificate for the self-hosted web app. Please note that Visual Studio should run with elevated elevated privileges.

Nevertheless, with a careful consideration, integration tests can be authored to run against a self-hosted or cloud-hosted web API.

This provides a tremendous productivity boost, given the easy ability to run integration tests in process, with a setup cost that is negligible as described in this post.


It was suggested in the comments to utilize In-Memory hosting instead of Self-Hosting solution. (See details here)

Another nuget package should be referenced: Microsoft.Owin.Testing. The resulting in-memory api call is executed as follows:

using (var server = TestServer.Create<Startup>())
    // Execute test against the web API.
    var result = await server.HttpClient.GetAsync("/api/values/");

Unfortunately, in-memory solution doesn’t work for me out of the box. Seems like it can’t handle authentication. I use UseJwtBearerAuthentication (JWT bearer token middleware) and my api calls result in 401.

Application Development and Integration, WebAPI
, ,

Leave a Reply

newest oldest most voted
Notify of
Has AlTaiar

Great post and very informative, thanks Boris

Filip W (@filip_woj)

Please don’t run use self hosting for integration tests using, it’s a bad practice. There is a bunch of reasons for that but the main ones are: a) you may run into port permission issues on the machine that executes the tests b) imagine a CI server running plenty of tests in parallel – then they might all try to setup a self host on the same port and potentially fail as they would be interfering with each other c) you end up relying on the machine’s networking stack, and if that is misbehaving, then your tests will fail for… Read more »

Thomas Harris

Yes I went for the test server way also This runs it all In memory and the CI problems disappear.

I actually wrote a similar blog only the other day using the nuget.

Only down side of this so far is parallel running test, seems to mess up on occasion.


vps offshore

Good Article!

Simon Green
Simon Green

I have following your post and have got an integration test which starts a web app working when it runs within Visual Studio.

Unfortunately I have no such joy when I get our TeamCity CI server to run the test. In this case, I get the error:

System.MissingMemberException: The server factory could not be located for the given input: Microsoft.Owin.Host.HttpListener

All the tests run one at a time, so it’s nothing to do with the parallel test running issues. If anyone has any ideas why I might have this problem, I’d love to hear them!

Simon Waight

Hi Simon – recommend taking a look at this Stack Overflow post solution to see if it helps you out.


“Unfortunately, in-memory solution doesn’t work for me out of the box. Seems like it can’t handle authentication. I use UseJwtBearerAuthentication (JWT bearer token middleware) and my api calls result in 401.” i faced the same, but if i do some thing like this. /*get token*/ InitializeServer(); string token = GetToken(); TearDown(); /*restart server again and test auth*/ Setup(); InitializeServer(); [Authorize] attr works i will update my codes at but for me the authProvider was n’t working as expected, which forced me to use controller to get token


Is it possible to use OWIN for testing a ASP.NET Core project?

Follow Us!

Kloud Solutions Blog - Follow Us!