ASP.NET Core 2.2 & 3 REST API #15 —Integration Testing

3 min readJul 24, 2019

We are also going to talk about unit tests at a later episode. The reason why we tackle integration testing is because this technique is pretty new in the .net core land and less people are familiar with it.

What is Integration Testing

It’s a way of ensuring that our application works properly and as expected while interacting with other components of the system, including but not limited to: networks, databases, middleware, pipelines or any other thing you have integrated with your REST API

We are going to run our REST API in-memory and perform requests on it, checking and evaluating expected state, behaviour and returned values.

We start by creating a new Project under our solution, called Tweetbook.IntegrationTests (it’ s just a blank test by default)

We want to run code against our running API.

We are going to use our WebApplicationFactory that was added in ASP.Net Core 2. We need several packages for that: Microsoft.AspNetCore.Mvc.Testing , Microsoft.AspNetCore.App

We are going to use an HttpClient . That’s a special client, originating from our WebApplicationFactory . We need to reference our other Tweetbook project for that. This way, we can actually target our project that runs in-memory instead of spinning it up manually!

Let’s run a simple unit test and set a breakpoint to see what we get back:

We can see that we get a special in-memory server that only this client can access.

We can also normally talk to this API as if it was an in memory application.

We get an expected HTTP 401 Unauthorised response because we are not using a JWT.

Let’s get started

We are going to create a new IntegrationTest class that we are going to use as a base for every other test class we are going to create. This would contain the boilerplate for the in memory rest api, some authentication stuff like getting the JWT and injecting the auth headers.

xUnit is going to run each unit test once, meaning that this auth and setup code is going to run once per test (the IntegrationTest.cs is going to be instantiated once per test as well). We could use setup-teardown, but since we are using EF, we can re-configure our DataContext to use an EF Core in-memory database instead of a true SQL Server one.

If you need acceptance testing you need to spin up the actual application in docker.

Also, let’s use some naming conventions (you don’t have to follow it, but if you don’t currently know how to name tests properly, it would be best to stick with this):